Cómo TypeScript hizo mantenibles los frontends grandes en JavaScript

Por qué las grandes bases de código frontend se vuelven difíciles de mantener

Un frontend que empezó como “solo unas páginas” puede crecer silenciosamente hasta tener miles de archivos, docenas de áreas de funcionalidad y varios equipos desplegando cambios cada día. A ese tamaño, la flexibilidad de JavaScript deja de sentirse como libertad y empieza a sentirse como incertidumbre.

El costo oculto del “funciona”

En una gran app en JavaScript, muchos errores no aparecen donde se introdujeron. Un pequeño cambio en un módulo puede romper una pantalla lejana porque la conexión entre ellos es informal: una función espera cierta forma de datos, un componente asume que una prop siempre está presente, o un helper devuelve distintos tipos según la entrada.

Puntos de dolor comunes incluyen:

• Contratos poco claros entre módulos: puedes pasar casi cualquier cosa a cualquier parte, así que muchas veces aprendes los requisitos leyendo detalles de implementación.
• Fallas solo en tiempo de ejecución: los problemas aparecen en QA, en producción o en una ruta de usuario específica—porque nada comprueba las expectativas del código por adelantado.
• Desarrollo impulsado por el miedo: los ingenieros evitan mejorar el código porque no pueden predecir qué se romperá.

Qué significa “mantenible” en la práctica

Mantenibilidad no es una vaga puntuación de “calidad de código”. Para los equipos, normalmente significa:

• Velocidad para cambiar: añadir funcionalidades o corregir errores sin necesitar un modelo mental completo de toda la app.
• Confianza: saber que si cometiste un error, lo sabrás rápido—idealmente antes de lanzar.
• Legibilidad: poder entender lo que espera y devuelve un fragmento de código sin perseguir cinco archivos y un depurador en tiempo de ejecución.

Dónde encaja TypeScript (y dónde no)

TypeScript es JavaScript + tipos. No reemplaza la plataforma web ni exige un nuevo runtime; añade una capa en tiempo de compilación que describe formas de datos y contratos de API.

Dicho esto, TypeScript no es magia. Añade algo de esfuerzo inicial (definir tipos, fricciones ocasionales con patrones dinámicos). Pero ayuda sobre todo donde los frontends grandes sufren: en los límites de los módulos, en utilidades compartidas, en UIs con muchos datos y durante refactors donde “creo que esto es seguro” debe convertirse en “sé que esto es seguro”.

Qué introdujo TypeScript y por qué los equipos lo adoptaron

TypeScript no reemplazó JavaScript tanto como lo extendió con algo que los equipos llevaban años queriendo: una forma de describir qué debe aceptar y devolver el código, sin renunciar al lenguaje y al ecosistema que ya usaban.

Una línea del tiempo rápida: de experimento a opción por defecto

• Mediados de 2000 a principios de 2010: experimentos de tipado opcional (como ActionScript, Closure types, Flow) mostraron el valor de la información de tipos, pero la adopción estuvo fragmentada.
• 2012: Microsoft lanzó TypeScript, con el objetivo de ofrecer mejor tooling y compatibilidad con JavaScript.
• Finales de 2010 en adelante: con las SPA y las UIs dirigidas por componentes como estándar, el uso de TypeScript se aceleró y muchos equipos empezaron a considerarlo la opción por defecto para trabajo frontend nuevo.

La complejidad frontend superó al “solo JavaScript”

A medida que los frontends se convirtieron en aplicaciones completas, acumularon más piezas móviles: grandes single-page apps, librerías de componentes compartidas, múltiples integraciones de API, gestión de estado compleja y pipelines de build. En una base de código pequeña puedes “tenerlo en la cabeza”. En una grande necesitas formas más rápidas de responder preguntas como: ¿Qué forma tiene este dato? ¿Quién llama a esta función? ¿Qué se rompe si cambio esta prop?

Encajó en los flujos existentes de JavaScript y npm

Los equipos adoptaron TypeScript porque no exigía una reescritura desde cero. Funciona con paquetes npm, bundlers familiares y configuraciones de test comunes, y se compila a JavaScript plano. Eso hizo que fuera más fácil introducirlo de forma incremental, repo por repo o carpeta por carpeta.

Tipado gradual: la clave de la adopción

El “tipado gradual” significa que puedes añadir tipos donde aporten más valor y mantener otras áreas poco tipadas por ahora. Puedes empezar con anotaciones mínimas, permitir archivos JavaScript y mejorar la cobertura con el tiempo—obteniendo autocompletado mejorado y refactors más seguros sin necesitar perfección desde el día uno.

Los tipos como contratos vivos entre partes de la app

Los grandes frontends son en realidad colecciones de pequeños acuerdos: un componente espera ciertas props, una función espera ciertos argumentos y los datos de la API deberían tener una forma predecible. TypeScript hace esos acuerdos explícitos convirtiéndolos en tipos—una especie de contrato vivo que permanece junto al código y evoluciona con él.

Contratos para funciones, componentes y datos

Un tipo dice: “esto es lo que debes proporcionar y esto es lo que obtendrás”. Eso aplica igual a helpers minúsculos y a grandes componentes de UI.

type User = { id: string; name: string };

function formatUser(user: User): string {
  return `${user.name} (#${user.id})`;
}

type UserCardProps = { user: User; onSelect: (id: string) => void };

Con estas definiciones, cualquiera que llame a formatUser o renderice UserCard puede ver inmediatamente la forma esperada sin leer la implementación. Esto mejora la legibilidad, especialmente para miembros nuevos del equipo que aún no saben dónde “viven las reglas reales”.

Prevenir errores comunes antes de enviarlos

En JavaScript puro, un error tipográfico como user.nmae o pasar un tipo de argumento equivocado suele llegar a tiempo de ejecución y fallar solo cuando se ejecuta esa ruta de código. Con TypeScript, el editor y el compilador señalan los problemas temprano:

• Propiedad equivocada: acceder a user.fullName cuando solo existe name
• Argumento equivocado: llamar a onSelect(user) en lugar de onSelect(user.id)

Son errores pequeños, pero en una base de código grande generan horas de depuración y trabajo en pruebas.

Comprobaciones en tiempo de compilación vs comportamiento en tiempo de ejecución (sin jerga)

Las comprobaciones de TypeScript ocurren mientras construyes y editas tu código. Puede decirte “esta llamada no cumple el contrato” sin ejecutar nada.

Lo que no hace es validar datos en tiempo de ejecución. Si una API devuelve algo inesperado, TypeScript no detendrá la respuesta del servidor. En su lugar, ayuda a escribir código que asuma una forma clara y te empuja hacia la validación en tiempo de ejecución donde realmente se necesite.

El resultado es una base de código donde los límites están más claros: los contratos se documentan en tipos, los desajustes se detectan temprano y los nuevos contribuyentes pueden cambiar código con seguridad sin adivinar lo que otras partes esperan.

Herramientas que facilitan entender y navegar el código

TypeScript no solo detecta errores en el build—convierte tu editor en un mapa del código. Cuando un repo crece a cientos de componentes y utilidades, la mantenibilidad suele fallar no porque el código sea “malo”, sino porque la gente no puede responder rápido a preguntas simples: ¿Qué espera esta función? ¿Dónde se usa? ¿Qué se romperá si la cambio?

Autocompletado que refleja la intención real

Con TypeScript, el autocompletado es más que una comodidad. Cuando escribes una llamada a función o una prop de componente, el editor puede sugerir opciones válidas basadas en tipos reales, no en conjeturas. Eso significa menos viajes a los resultados de búsqueda y menos “¿cómo se llamaba esto otra vez?”.

También obtienes documentación en línea: nombres de parámetros, campos opcionales vs obligatorios y comentarios JSDoc visibles donde trabajas. En la práctica, reduce la necesidad de abrir archivos extra solo para entender cómo usar una pieza de código.

“Ir a definición” y navegación rápida

En repos grandes, se pierde tiempo buscando manualmente—grep, desplazamientos, múltiples pestañas. La información de tipos hace que las funciones de navegación sean mucho más precisas:

• Ir a definición salta al símbolo exacto que usas (no a una función con nombre similar).
• Buscar todas las referencias es más confiable porque el editor sabe qué cuenta como el mismo tipo o símbolo.

Esto cambia el trabajo diario: en vez de mantener todo el sistema en la cabeza, puedes seguir un rastro fiable a través del código.

Revisiones de código más claras

Los tipos hacen la intención visible durante la revisión. Un diff que añade userId: string o devuelve Promise<Result<Order, ApiError>> comunica restricciones y expectativas sin largas explicaciones en los comentarios.

Los revisores pueden centrarse en el comportamiento y los casos borde en lugar de debatir qué “debería” ser un valor.

Editores: útiles, no obligatorios

Muchos equipos usan VS Code por su soporte fuerte a TypeScript, pero no necesitas un editor específico para beneficiarte. Cualquier entorno que entienda TypeScript puede proporcionar la misma clase de navegación y sugerencias.

Si quieres formalizar estos beneficios, los equipos a menudo los acompañan con convenciones ligeras en /blog/code-style-guidelines para mantener el tooling consistente en todo el proyecto.

Refactorizar con confianza en lugar de con miedo

Refactorizar un frontend grande solía sentirse como caminar por una habitación llena de trampas: podías mejorar una zona, pero no sabías qué se rompería a dos pantallas de distancia. TypeScript cambia eso convirtiendo muchos cambios riesgosos en pasos controlados y mecánicos. Cuando cambias un tipo, el compilador y tu editor muestran todos los lugares que dependen de él.

Refactors a gran escala más seguros

TypeScript hace los refactors más seguros porque obliga a la base de código a mantenerse consistente con la “forma” que declaras. En lugar de confiar en la memoria o en una búsqueda a ciegas, obtienes una lista precisa de los sitios afectados.

Algunos ejemplos comunes:

• Renombrar props: si Button aceptaba isPrimary y lo renombras a variant, TypeScript marcará cada componente que siga pasando isPrimary.
• Cambiar la forma de respuesta de una API: si user.name pasa a ser user.fullName, la actualización del tipo mostrará todas las lecturas y suposiciones por toda la app.
• Mover archivos / cambiar exports: al reorganizar módulos, TypeScript ayuda a asegurar que las rutas de importación y los miembros exportados sigan alineados, especialmente combinado con acciones de IDE como “rename symbol” y “move file”.

Errores que apuntan exactamente a lo que hay que arreglar

El beneficio más práctico es la velocidad: tras un cambio, ejecutas el type checker (o simplemente observas tu IDE) y sigues los errores como una lista de tareas. No adivinas qué vista puede verse afectada: vas corrigiendo cada lugar que el compilador prueba que es incompatible.

Los límites (y por qué las comprobaciones en tiempo de ejecución aún importan)

TypeScript no atrapa todos los bugs. No puede garantizar que el servidor realmente envíe lo que prometió, o que un valor no sea null en un caso borde sorprendente. La entrada del usuario, respuestas de red y scripts terceros siguen requiriendo validación en tiempo de ejecución y estados de UI defensivos.

La ganancia es que TypeScript elimina una gran clase de “roturas accidentales” durante refactors, por lo que los bugs que quedan suelen ser más sobre comportamiento real—no por dejar nombres antiguos sin actualizar.

Manejar datos de APIs con más seguridad

Las APIs son donde empiezan muchos bugs frontend—no porque los equipos sean descuidados, sino porque las respuestas reales evolucionan con el tiempo: campos añadidos, renombrados, opcionales o temporalmente ausentes. TypeScript ayuda haciendo explícita la forma de los datos en cada punto de entrega, de modo que un cambio en un endpoint tenga más probabilidades de aparecer como error en compilación que como excepción en producción.

Tipar respuestas de API aclara las formas de datos

Cuando tipeas una respuesta de API (aunque sea de forma aproximada), fuerzas a la app a ponerse de acuerdo sobre qué es “un usuario”, “un pedido” o “un resultado de búsqueda”. Esa claridad se propaga rápidamente:

• Los componentes de UI saben qué pueden renderizar sin adivinar.
• Las funciones de mapeo de datos documentan la intención (por ejemplo, convertir céntimos a moneda).
• Los sitios que llaman dejan de pasar “lo que devolvió el servidor” a lo largo de la app.

Un patrón común es tipar el límite por donde entran los datos (tu capa de fetch), y pasar objetos tipados hacia adelante.

Campos opcionales, null y undefined: lidiando con la realidad

Las APIs en producción suelen incluir:

• Propiedades opcionales (presentes solo en algunos casos)
• Campos anulables (null usados intencionalmente)
• Campos ausentes (no incluidos en absoluto)

TypeScript te obliga a tratar estos casos deliberadamente. Si user.avatarUrl puede faltar, la UI debe proporcionar un fallback, o la capa de mapeo debe normalizarlo. Esto empuja la decisión “¿qué hacemos cuando falta?” a la revisión de código, en lugar de dejarlo al azar.

Tipos TypeScript vs validación en tiempo de ejecución

Las comprobaciones de TypeScript suceden en build time, pero los datos de API llegan en runtime. Por eso la validación en tiempo de ejecución puede seguir siendo útil—especialmente para APIs no confiables o cambiantes. Un enfoque práctico:

• Usa tipos TypeScript para velocidad de desarrollo y refactors seguros.
• Añade validación en tiempo de ejecución para endpoints críticos o cuando los fallos deben controlarse (mostrar un error amigable, registrar, reintentar).

Tipos generados (opcional, no obligatorio)

Los equipos pueden escribir tipos a mano, pero también pueden generarlos desde esquemas OpenAPI o GraphQL. La generación reduce la deriva manual, aunque no es obligatoria—muchos proyectos empiezan con unos pocos tipos de respuesta escritos a mano y adoptan la generación más adelante si compensa.

Mantenibilidad de componentes en frameworks UI modernos

Los componentes UI deberían ser bloques pequeños y reutilizables—pero en apps grandes a menudo se convierten en “mini-apps” frágiles con docenas de props, renderizado condicional y suposiciones sutiles sobre cómo son los datos. TypeScript ayuda a mantener estos componentes manejables al hacer explícitas esas suposiciones.

Props y estado tipados como guardarraíles

En cualquier framework moderno, los componentes reciben entradas (props/inputs) y gestionan datos internos (estado). Cuando esas formas no están tipadas, puedes pasar accidentalmente el valor equivocado y solo descubrirlo en tiempo de ejecución—a veces en una pantalla poco usada.

Con TypeScript, props y estado se convierten en contratos:

• Un componente puede declarar exactamente qué props espera, cuáles son opcionales y qué valores están permitidos.
• El estado puede modelarse para que situaciones “imposibles” no compilen (por ejemplo, cargar datos y mostrar contenido al mismo tiempo).

Estos guardarraíles reducen la cantidad de código defensivo (“if (x) …”) y hacen el comportamiento del componente más fácil de razonar.

Prevenir props desajustadas y estados de UI inválidos

Una fuente común de bugs en codebases grandes es el desajuste de props: el padre piensa que pasa userId, el hijo espera id; o un valor es a veces string y a veces número. TypeScript saca a la luz estos problemas inmediatamente donde se usa el componente.

Los tipos también ayudan a modelar estados de UI válidos. En lugar de representar una petición con booleanos sueltos como isLoading, hasError y data, puedes usar una unión discriminada como { status: 'loading' | 'error' | 'success' } con los campos apropiados para cada caso. Esto dificulta renderizar una vista de error sin mensaje o una vista de éxito sin datos.

Soporte agnóstico de framework: React, Vue, Angular

TypeScript se integra bien en los ecosistemas principales. Ya construyas componentes con React function components, la Composition API de Vue o los componentes basados en clases y plantillas de Angular, el beneficio central es el mismo: entradas tipadas y contratos de componente predecibles que las herramientas pueden entender.

Librerías de componentes compartidas: tipos como documentación para consumidores

En una librería compartida, las definiciones de TypeScript actúan como documentación actualizada para cada equipo consumidor. El autocompletado muestra las props disponibles, las pistas en línea explican qué hacen y los breaking changes se hacen visibles durante las actualizaciones.

En lugar de depender de una wiki que se queda obsoleta, la “fuente de la verdad” viaja con el componente—haciendo el reuso más seguro y reduciendo la carga de soporte para los mantenedores de la librería.

Mantener a equipos grandes alineados con código consistente

Los proyectos frontend grandes rara vez fallan porque una persona escribió “mal código”. Se vuelven dolorosos cuando muchas personas toman decisiones razonables de formas ligeramente distintas—nombres diferentes, formas de datos distintas, manejo de errores distinto—hasta que la app se siente inconsistente y difícil de predecir.

La consistencia supera las heroicas en bases de código multi-equipo

En entornos multi-equipo o multi-repo, no puedes confiar en que todos recuerden reglas no escritas. La gente rota, se unen contratistas, los servicios evolucionan y “la forma de hacer aquí” se convierte en conocimiento tribal.

TypeScript ayuda haciendo explícitas las expectativas. En lugar de documentar qué debería aceptar o devolver una función, lo codificas en tipos que todo llamador debe satisfacer. Eso convierte la consistencia en comportamiento por defecto en lugar de una guía fácil de pasar por alto.

Tipos como convenciones compartidas (y menos conocimiento tribal)

Un buen tipo es un pequeño acuerdo que todo el equipo comparte:

• Un User siempre tiene id: string, no a veces number.
• Las props de un componente son estables y fáciles de descubrir, no “mira cómo otros archivos lo llaman”.
• Las respuestas de API se validan/normalizan una vez y el resto de la UI trabaja con una forma predecible.

Cuando estas reglas viven en tipos, los nuevos compañeros aprenden leyendo código y usando las pistas del IDE, no preguntando en Slack o buscando a un ingeniero senior.

Combinar TypeScript con linting y formateo

TypeScript y linters resuelven problemas distintos:

• TypeScript comprueba corrección a través de límites de archivos (por ejemplo, llamar funciones con los datos correctos).
• Linting (ESLint) aplica convenciones de calidad y estilo (por ejemplo, no variables sin usar, imports consistentes).
• Formateo (Prettier) estandariza el aspecto del código (saltos de línea, comillas), reduciendo debates en las revisiones.

Usados juntos, hacen que los PR sean sobre comportamiento y diseño—no sobre detalles menores.

Mantener los tipos legibles (evitar la complejidad)

Los tipos pueden convertirse en ruido si están sobreingenierizados. Algunas reglas prácticas para mantenerlos accesibles:

• Prefiere tipos nombrados simples (type OrderStatus = ...) sobre genéricos profundamente anidados.
• Modela los datos que realmente usas, no todas las formas posibles.
• Usa unknown + narrowing intencional en lugar de esparcir any.

Los tipos legibles actúan como buena documentación: precisos, actuales y fáciles de seguir.

Rutas prácticas de migración de JavaScript a TypeScript

Migrar un frontend grande de JavaScript a TypeScript funciona mejor cuando se trata como una serie de pasos pequeños y reversibles—no como una reescritura total. El objetivo es aumentar seguridad y claridad sin paralizar el trabajo de producto.

Enfoques comunes que realmente entregan

1) “Archivos nuevos primero”
Empieza escribiendo todo el código nuevo en TypeScript mientras dejas los módulos existentes tal cual. Esto impide que la base de código JavaScript siga creciendo y permite que el equipo aprenda gradualmente.

2) Conversión módulo a módulo
Elige un límite a la vez (una carpeta de feature, un paquete de utilidades compartidas o una librería de componentes) y conviértelo por completo. Prioriza módulos muy usados o que cambian a menudo—esos dan el mayor retorno.

3) Pasos de estrictness
Incluso tras cambiar la extensión de archivos, puedes avanzar hacia garantías más fuertes por etapas. Muchos equipos empiezan permisivos y endurecen reglas con el tiempo a medida que los tipos se completan.

Conceptos clave de configuración (tsconfig)

Tu tsconfig.json es el volante de dirección de la migración. Un patrón práctico es:

• Empezar permitiendo que TypeScript compile sin romper el build.
• Activar strict más tarde (o habilitar flags estrictos uno a uno).
• Usar endurecimiento incremental: establecer criterios claros para cuándo una carpeta/paquete puede “graduarse” a configuraciones más estrictas.

Esto evita una enorme acumulación inicial de errores de tipo y mantiene al equipo enfocado en cambios que importan.

Librerías de terceros y tipos faltantes

No todas las dependencias traen buenos typings. Opciones típicas:

• Instalar tipos comunitarios (a menudo vía @types/...).
• Añadir declaraciones locales mínimas para lo que realmente usas.
• Aislar límites no tipados y mantener any contenido en una pequeña capa adaptadora.

Regla práctica: no bloquees la migración esperando tipos perfectos—crea un límite seguro y sigue adelante.

Evitar que se estanque la entrega

Fija pequeños hitos (por ejemplo, “convertir utilidades compartidas”, “tipar el cliente de API”, “estricto en /components”) y define reglas de equipo simples: dónde es obligatorio TypeScript, cómo tipar nuevas APIs y cuándo se permite any. Esa claridad mantiene el progreso constante mientras las funcionalidades siguen desplegándose.

Si tu equipo también moderniza cómo construye y entrega apps, una plataforma como Koder.ai puede ayudar a avanzar más rápido en estas transiciones: puedes iniciar frontends React + TypeScript y backends Go + PostgreSQL mediante un flujo de trabajo basado en chat, iterar en un “modo de planificación” antes de generar cambios y exportar el código fuente cuando estés listo para incorporarlo al repo. Bien usado, eso complementa el objetivo de TypeScript: reducir la incertidumbre sin sacrificar la velocidad de entrega.

Compensaciones y conceptos erróneos comunes

TypeScript facilita cambiar frontends grandes, pero no es una mejora gratuita. Los equipos suelen notar el coste sobre todo durante la adopción y en periodos de cambio de producto intenso.

Puntos de fricción comunes

La curva de aprendizaje es real—especialmente para desarrolladores nuevos en genéricos, uniones y narrowing. Al principio puede parecer que “luchas contra el compilador”, y los errores de tipo aparecen justo cuando intentas moverte rápido.

También añadirás complejidad a la build. La comprobación de tipos, la transpileación y a veces configuraciones separadas para tooling (bundler, tests, linting) introducen más piezas móviles. El CI puede volverse más lento si la comprobación de tipos no está afinada.

Dónde los tipos pueden frenarte

TypeScript puede convertirse en un lastre cuando los equipos tipan todo en exceso. Escribir tipos extremadamente detallados para código de corta vida o scripts internos suele costar más de lo que aporta.

Otro freno común son los genéricos poco claros. Si la firma de tipos de una utilidad es demasiado ingeniosa, la siguiente persona no la entenderá, el autocompletado se volverá ruidoso y cambios simples se convertirán en resolver un puzzle de tipos. Eso es un problema de mantenibilidad, no una victoria.

Balancear velocidad y seguridad

Los equipos pragmáticos tratan los tipos como una herramienta, no como un objetivo. Directrices útiles:

• Prefiere tipos simples y legibles sobre tipos perfectos.
• Usa unknown (con comprobaciones en tiempo de ejecución) cuando los datos no son confiables, en lugar de forzarlos a any.
• Permite escapatorias (any, @ts-expect-error) con moderación y comentarios que expliquen por qué y cuándo eliminarlas.

Qué no soluciona TypeScript

Un malentendido común: “TypeScript previene todos los bugs.” Previene una categoría de errores, mayormente alrededor de suposiciones incorrectas en el código. No evita fallos en tiempo de ejecución como timeouts de red, payloads de API inválidos o que JSON.parse lance una excepción.

Tampoco mejora el rendimiento en runtime por sí mismo. Los tipos de TypeScript se eliminan en build; cualquier sensación de mayor velocidad viene de refactors más seguros y menos regresiones, no de una ejecución más rápida.

Lista de comprobación de mantenibilidad para frontends TypeScript

Las grandes bases TypeScript se mantienen manejables cuando los equipos tratan los tipos como parte del producto—no como una capa opcional que añades después. Usa esta checklist para detectar qué funciona y qué está añadiendo fricción silenciosa.

Checklist: qué estandarizar

• Nivel de estrictness: Apunta a "strict": true (o a un plan documentado para llegar allí). Si no puedes, habilita opciones estrictas de forma incremental (por ejemplo noImplicitAny, luego strictNullChecks).
• Tipos compartidos: Mantén tipos de API/dominio en un lugar compartido (a menudo una carpeta /types o /domain), y haz real la “fuente de la verdad”—los tipos generados desde OpenAPI/GraphQL son incluso mejores.
• Prácticas de revisión: En la revisión de código, comprueba que haya “diseño impulsado por tipos” (entradas/salidas claras) y rechaza cambios que añadan incertidumbre sin motivo.

Patrones que pagan a largo plazo

Prefiere módulos pequeños con límites claros. Si un archivo combina fetch, transformación y lógica de UI, se vuelve difícil de cambiar con seguridad.

Usa tipos significativos en lugar de ingeniosos. Por ejemplo, alias explícitos UserId y OrderId pueden evitar confusiones, y uniones estrechas ("loading" | "ready" | "error") hacen legibles las máquinas de estado.

Señales de alarma para arreglar pronto

• any que se extiende por la codebase, especialmente en utilidades compartidas.
• Afirmaciones de tipo por todas partes (as Something) para silenciar errores en lugar de modelar la realidad.
• Modelos de datos duplicados (formas ligeramente distintas de User en carpetas diferentes), lo que garantiza deriva.

Cuándo merece la pena TypeScript (y cuándo JS está bien)

TypeScript suele valer la pena para equipos de varias personas, productos de larga duración y apps que se refactorizan con frecuencia. JavaScript plano puede ser suficiente para prototipos pequeños, sites de marketing temporales o código muy estable donde el equipo va más rápido con menos tooling—siempre y cuando seas honesto sobre la compensación y mantengas el alcance contenido.