Has escrito la misma pantalla de Nómada Tareas cuatro veces: en JavaScript puro, en React, en Vue y en Angular. Cada versión hace exactamente lo mismo —la lista de tareas, el filtro por responsable y el botón de marcar como hecha, con los números canónicos intactos— y cada una lo hace de una forma distinta, con costes distintos. Ahora toca la pregunta que da sentido a todo el módulo y que ningún tutorial responde bien: cómo se elige. No con una tabla de estrellas ni con la opinión de una charla, sino con un método que puedas defender ante tu equipo y ante ti mismo dentro de tres años. En esta lección verás los criterios que de verdad importan —producto, equipo, mercado laboral, longevidad, rendimiento, SEO, accesibilidad, ecosistema y coste de contratación y formación— con una tabla de ponderación que puedes rellenar; la comparativa técnica honesta de los cuatro enfoques en una tabla de doble entrada; las cuatro versiones de la misma pantalla una al lado de otra con sus métricas y una conclusión matizada; la decisión que suele importar más que la del framework —dónde se renderiza: cliente, servidor, estático o híbrido, con SPA, SSR, SSG e islas y sus meta-frameworks—; los criterios de SEO y accesibilidad, y por qué ninguno de los cuatro te salva de hacerlo mal; cómo evaluar una tecnología nueva sin caer en modas, con el prototipo de un día sobre tu caso más difícil; y las estrategias de migración sin reescrituras totales. Es la última lección del módulo, y cierra con lo que no caduca —el lenguaje, el DOM, HTTP, las pruebas, el rendimiento: exactamente lo que has aprendido— frente a lo que sí.

1. Por qué esta lección existe
2. Los criterios que importan
3. La tabla de ponderación que puedes rellenar
4. Cómo se usa: la decisión de Taller Nómada, paso a paso
5. La comparativa técnica honesta
6. Las cuatro versiones de la misma pantalla, con métricas
7. Qué compensa según el contexto
8. La decisión que suele importar más: dónde se renderiza
9. SPA: renderizado en el cliente
10. SSR: renderizado en el servidor
11. SSG: generación estática
12. Islas y renderizado híbrido
13. Los meta-frameworks en una tabla
14. SEO: qué te salva un framework y qué no
15. Accesibilidad: ninguno te salva de hacerlo mal
16. Cómo evaluar una tecnología nueva sin caer en modas
17. El prototipo de un día con el caso más difícil
18. Estrategias de migración sin reescrituras totales
19. Web components como frontera
20. Lo que no caduca frente a lo que sí
21. El Módulo 11: JavaScript puro, ahora por decisión
22. Errores Comunes y Consejos
23. Ejercicios
24. Conclusión

Hay dos formas de elegir tecnología, y las dos se ven a diario.

La primera es la que domina: se elige lo que se conoce, lo que se ha visto en una charla, lo que usa la empresa de al lado, o lo que aparece más veces en las ofertas de empleo. No es irracional —el mercado laboral es un criterio legítimo, y lo veremos— pero se aplica sin decirlo, y por tanto sin poder discutirlo.

La segunda es la que vas a aprender aquí: enumerar los criterios, ponderarlos según el contexto, medir el propio caso y decidir con los datos delante. No garantiza acertar; garantiza que la decisión se pueda explicar, revisar y corregir. Y sobre todo garantiza que sea tuya.

Un aviso de honestidad antes de empezar, porque esta lección no va a darte un ganador. Los cuatro enfoques que has visto son buenos, y hay aplicaciones excelentes construidas con cada uno. Cualquier texto que te diga que uno es objetivamente superior está ignorando el contexto, que es exactamente lo que determina la respuesta. Lo que sí puedo darte es el método, las tablas para aplicarlo y los datos de tu propio proyecto medido cuatro veces.

Ocho criterios, y ninguno es «cuál tiene mejor rendimiento en un banco de pruebas».

1 · Necesidades del producto. ¿Cuánta interactividad tiene? ¿Cuántas pantallas? ¿Hay formularios complejos, tiempo real, gráficos, edición colaborativa? Una web con un menú desplegable y una aplicación de gestión con permisos por rol no son el mismo problema, aunque las dos «sean web».

2 · Tamaño y experiencia del equipo. Una persona sola optimiza para velocidad de escritura y baja ceremonia. Seis personas optimizan para convenciones compartidas, contratos explícitos y capacidad de revisar el código ajeno. Y lo que el equipo ya sabe vale más que cualquier ventaja técnica marginal: la productividad de un equipo experto en una herramienta supera casi siempre la de un equipo novato en otra mejor.

3 · Mercado laboral local. Es un criterio incómodo pero real, y funciona en dos direcciones: si contratas, necesitas encontrar gente; si buscas empleo, necesitas que tu experiencia sea demandada donde vives. Y es local: las proporciones entre React, Vue y Angular varían mucho entre países y entre sectores. Mira ofertas reales de tu ciudad, no encuestas globales.

4 · Longevidad y estabilidad del proyecto. ¿Cuánto tiene que durar esto? Un proyecto de tres meses puede permitirse una tecnología nueva. Uno que debe funcionar diez años sin que nadie lo toque tiene que apostar por estabilidad, política de versiones clara y migraciones automáticas — o por no depender de nada.

5 · Requisitos de rendimiento y SEO. ¿Cuál es tu presupuesto de bytes? ¿Tus usuarios están en fibra o en 3G? ¿El contenido debe indexarse? Estas preguntas suelen decidir dónde se renderiza (apartado 8) antes que qué framework se usa.

6 · Accesibilidad. ¿Hay obligación legal? ¿Público diverso? ¿Uso intensivo de teclado? Ningún framework te la da hecha, pero unos ponen más fácil hacerlo bien que otros.

7 · Ecosistema. ¿Necesitas una tabla de datos avanzada, un editor enriquecido, gráficos complejos, un calendario? Cuanto más específica sea la necesidad, más pesa el tamaño del ecosistema.

8 · Coste de contratación y formación. Cuánto cuesta traer a alguien productivo y cuánto tiempo pasa hasta que lo es. Se mide en semanas, y se paga cada vez que entra alguien nuevo.

Fíjate en algo: cinco de los ocho no son técnicos. Esa proporción es representativa de cómo se toman las decisiones que salen bien.

El método es sencillo. Para cada criterio, asigna un peso de 1 a 5 según lo que importe en tu contexto —no en abstracto—, puntúa cada opción de 1 a 5, multiplica y suma.

Tres reglas de uso, sin las cuales la tabla es un adorno:

Regla 1 · Los pesos se ponen antes de puntuar. Si decides los pesos después de ver las puntuaciones, estás justificando una decisión ya tomada. Es el sesgo más común y el más fácil de evitar.

Regla 2 · Un peso de 5 significa que puede vetar. Si el mercado laboral local pesa 5 y una opción saca 1, esa opción está descartada aunque gane en total. Los criterios eliminatorios no se promedian.

Regla 3 · Las puntuaciones se justifican con una frase. «React saca 4 en ecosistema porque la tabla de datos que necesitamos existe y está mantenida.» Sin la frase, el número es una opinión disfrazada de dato.

Y una advertencia sobre el instrumento: la tabla no decide, ordena el pensamiento. Si el resultado te incomoda, casi siempre significa que hay un criterio que no has escrito o un peso mal puesto. Eso también es información valiosa.

Hagámoslo con un caso concreto. Marta quiere convertir Nómada Tareas en un producto para veinte talleres de coworking: cinco pantallas, permisos por rol, informes, edición colaborativa en tiempo real, un equipo de cuatro personas y un horizonte de cinco años.

Paso 1 · Los pesos, con su justificación:

Paso 2 · Las puntuaciones, cada una con su frase:

Algunas justificaciones, para que se vea el razonamiento:

• JS puro saca 1 en «equipo de cuatro»: cada convención habría que inventarla, escribirla y hacerla cumplir sin ayuda de herramientas. Es el problema 8 de 10-01, y con cuatro personas es caro.
• JS puro saca 5 en longevidad: es el único que seguirá funcionando dentro de diez años sin actualizar nada.
• Angular saca 5 en «equipo de cuatro»: convenciones impuestas, tipado obligatorio y contratos explícitos son exactamente lo que necesita un equipo que revisa el código ajeno.
• Angular saca 2 en formación: dos personas tendrían que aprender TypeScript, decoradores, inyección de dependencias, señales y RxJS.
• JS puro saca 4 en accesibilidad: no porque el framework la impida, sino porque escribir el HTML a mano hace más visible qué elementos se están usando; con un framework es más fácil acabar con un <div> con onClick.

Paso 3 · Leer el resultado con criterio. Los tres frameworks están muy cerca (125, 131, 136) y JavaScript puro queda claramente descartado para este caso. Una diferencia de once puntos sobre 130 no es una diferencia: está dentro del ruido de las puntuaciones. La lectura correcta no es «gana Angular», sino:

Para este contexto, cualquiera de los tres frameworks es una decisión defendible y JavaScript puro no lo es. La elección final debe hacerse con el criterio de desempate que la tabla no captura: qué conoce ya el equipo, y qué se puede prototipar en un día (apartado 17).

Ese es el uso honesto de una tabla de ponderación: descartar lo que no encaja y reconocer cuándo hay empate, no fabricar una precisión que no existe.

Ahora la tabla de doble entrada de los cuatro enfoques, con lo que has visto en las cinco lecciones anteriores.

Dos filas merecen un comentario porque suelen malinterpretarse.

La de «fragmentación» de React no es solo un defecto. Que haya cuatro enrutadores es un coste para un equipo pequeño que tiene que elegir, y una ventaja para uno que necesita algo que la solución oficial no cubre. La misma característica se lee al revés según el contexto.

La de «tamaño base» importa menos de lo que parece. Cuarenta kilobytes comprimidos son unos 200 ms en una conexión mala, y suelen quedar sepultados por una sola imagen sin optimizar o por una petición de datos lenta. Solo es determinante en dos escenarios: widgets incrustados en páginas ajenas, y sitios de contenido donde la mayoría de los visitantes ve una página y se va.

Y aquí está lo que hace esta lección distinta de cualquier comparativa: has escrito las cuatro. Estos son los datos de la misma pantalla —lista de tareas, filtro por responsable, botón de avanzar— con el mismo backlog canónico de 6 tareas y los mismos números de salida.

Las cifras de peso y de primera pintura son órdenes de magnitud medidos en condiciones equivalentes, no marcas absolutas: cambian con la versión, con la configuración de compilación y con lo que uses de cada framework. Lo que no cambia es la relación entre ellas, que es lo que interesa para decidir.

Y ahora la lectura honesta, columna a columna:

JavaScript puro gana en peso, en peticiones y en tiempo hasta la primera pintura. No es una sorpresa: no hay motor que descargar. También gana en dependencias, que es el criterio de longevidad. Y pierde estrepitosamente en dos filas: las 60 líneas de infraestructura que tú mantienes y pruebas —reconciliar, crearElemento, $, $$, la delegación—, y el riesgo de olvido en la limpieza y en las claves, que son fallos reales que ya sufriste en 06-06 y en 09-03.

Vue tiene el mejor equilibrio en esta pantalla concreta: menos líneas que ninguno, un solo fichero por componente con estilos aislados, una dependencia y el motor más ligero de los tres.

React está muy cerca en líneas y compra el ecosistema más grande, a cambio de la memoización manual que 10-02 obligaba a discutir y de un motor algo más pesado.

Angular es el más verboso y el más pesado, y a cambio es el único donde el fallo de la clave es imposible, el tipado viene de serie y el estado compartido no necesita ninguna decisión.

Una precisión importante sobre las 40 líneas de dominio: son exactamente el mismo fichero en las cuatro versiones. SIGUIENTE, ETIQUETA, PESOS, HOY, estaVencida, horasAbiertas. Esa fila es la prueba empírica de la disciplina que 10-01 recomendaba: el framework se lleva la vista, no la aplicación.

Con los datos anteriores, la conclusión matizada:

Y el criterio general que resume todas las filas:

El framework compensa cuando el coste de mantener tu propia infraestructura supera al coste de descargar y aprender la suya. Ese punto llega antes de lo que la gente cree con equipos grandes, y mucho más tarde de lo que la gente cree con una sola persona.

Aquí está la afirmación más útil de toda la lección, y la que más gente descubre tarde:

Dónde se renderiza tu HTML afecta más al rendimiento percibido, al SEO y a la arquitectura que qué framework uses.

La razón es aritmética. Cambiar de React a Vue te ahorra unos 10 kB y algunos milisegundos de actualización. Cambiar de renderizado en cliente a renderizado en servidor o estático puede llevarte de 1,9 s de LCP a 0,6 s, y de «Google ve una página vacía» a «Google ve el contenido completo». Es un orden de magnitud más de impacto, y sin embargo se discute muchísimo menos.

Los cuatro enfoques, con el mismo esquema para poder compararlos:

Es lo que has hecho todo el curso y lo que hacen las cuatro versiones de la pantalla. El servidor envía un HTML casi vacío y el JavaScript construye la interfaz.

A favor: navegación instantánea entre pantallas una vez cargado; interacciones muy ricas sin ir al servidor; despliegue sencillo (ficheros estáticos); y una separación limpia entre frontend y API.

En contra: la primera carga es la más lenta de las cuatro —hay que descargar, analizar, ejecutar, pedir datos y pintar, en cadena—; el HTML inicial está vacío, lo que perjudica al SEO y a cualquier cosa que lea la página sin ejecutar JavaScript; y si el JavaScript falla, no hay nada.

Cuándo es lo correcto: aplicaciones detrás de un inicio de sesión, herramientas internas, paneles de datos, editores. Todo aquello donde el SEO no importa y donde el usuario abre la aplicación una vez y la usa durante horas — que es exactamente el caso de Nómada Tareas.

El servidor ejecuta los componentes y envía HTML ya pintado. El navegador lo muestra de inmediato y después descarga el JavaScript para hidratar la página: adjuntar los manejadores de eventos y recuperar el estado, convirtiendo el HTML estático en la aplicación interactiva.

A favor: el contenido es visible mucho antes (mejor LCP y FCP); el HTML es completo desde el primer byte, así que buscadores y previsualizaciones lo ven; funciona en dispositivos lentos, donde el coste está en ejecutar JavaScript.

En contra: necesitas un servidor ejecutando Node.js, con su coste, su escalado y su mantenimiento; el TTFB empeora, porque el servidor tiene que trabajar antes de responder; la hidratación tiene un coste real y produce el efecto incómodo de una página que se ve pero todavía no responde; y el código debe funcionar en los dos entornos, lo que obliga a vigilar cualquier uso de window o document.

Cuándo es lo correcto: comercio electrónico, medios, cualquier producto donde el contenido deba indexarse y donde la primera impresión determine si el usuario se queda.

El HTML se genera durante la compilación, una sola vez, y se sirve desde una CDN como ficheros estáticos.

A favor: es lo más rápido que existe —el servidor no calcula nada, solo entrega un fichero desde el nodo más cercano—; es lo más barato de alojar; es lo más seguro (no hay servidor que atacar); y es lo más fiable.

En contra: solo sirve para contenido que no cambia por usuario ni por petición; con miles de páginas, la compilación se vuelve lenta; y publicar un cambio requiere reconstruir, aunque la regeneración incremental mitiga esto reconstruyendo solo lo que cambió.

Cuándo es lo correcto: documentación, blogs, webs de producto, portafolios, catálogos que cambian pocas veces al día. Y sí: la web pública de Taller Nómada encaja aquí perfectamente.

La arquitectura de islas parte de una observación incómoda: en la mayoría de las páginas, casi nada necesita JavaScript. Un artículo, una ficha de producto o una página de tarifas son texto e imágenes; solo el buscador, el carrito o el calendario son interactivos.

La idea: generar HTML estático para toda la página y cargar JavaScript solo para los trozos interactivos, cada uno independiente, cada uno hidratándose cuando haga falta —al aparecer en pantalla, al interactuar, o nunca.

El resultado es que una página con tres widgets descarga el JavaScript de esos tres widgets, no el de la página entera. Y los widgets pueden estar escritos en frameworks distintos, porque cada isla es independiente.

Si esto te suena, es porque ya lo hiciste: el @defer (on viewport) de Angular en 10-05 y tu carga perezosa con IntersectionObserver de 09-05 son la misma idea aplicada dentro de una aplicación. Las islas la aplican a la arquitectura entera.

Cuándo es lo correcto: sitios de contenido con interactividad puntual. Es el punto óptimo de la web pública moderna, y la razón de que este enfoque haya crecido tanto.

Un meta-framework es una capa por encima del framework de componentes que aporta enrutado por ficheros, renderizado en servidor o estático, optimización de la compilación y despliegue.

La última fila merece atención, aunque parezca marginal. htmx cuestiona la premisa entera del módulo: en lugar de construir la interfaz en el navegador con estado local, el servidor devuelve HTML y el cliente lo inserta donde toca. Para aplicaciones de tipo formulario-y-lista —que son muchísimas— funciona sorprendentemente bien y elimina de golpe la sincronización de estado entre cliente y servidor, que es el problema 15 de 10-01. No es la respuesta para un editor colaborativo, pero es una respuesta legítima que conviene tener en el mapa.

Y la regla práctica para elegir modo de renderizado, que es más simple de lo que parece:

Los buscadores modernos ejecutan JavaScript, pero con matices que hacen que confiarse sea caro:

• La indexación de contenido renderizado en el cliente puede retrasarse días respecto a la del HTML directo, porque requiere una segunda pasada con más recursos.
• Otros rastreadores —redes sociales para las previsualizaciones, agregadores, herramientas de análisis, algunos buscadores— no ejecutan JavaScript en absoluto.
• Las Core Web Vitals que mediste en 09-01 (LCP, INP, CLS) son señales de posicionamiento, y una SPA parte con desventaja en LCP.

Lo que un framework te da: nada por sí mismo. Lo que te da un meta-framework con SSR o SSG: HTML completo en la primera respuesta, que es la mitad del problema.

Y lo que ningún framework te da, y sigue siendo responsabilidad tuya:

Fíjate en que la mayoría de esa tabla es HTML y decisiones de arquitectura, no framework. Es el mismo mensaje del apartado 20.

Aquí conviene ser tajante, porque es el punto donde más daño hace la falsa sensación de seguridad.

Ningún framework hace tu aplicación accesible. Al contrario: los frameworks facilitan escribir cosas inaccesibles, porque hacen igual de fácil escribir <button> que <div onClick>, y el segundo funciona con ratón perfectamente.

Los cuatro fallos que se repiten en aplicaciones construidas con framework, y que ya sabes evitar:

1 · Elementos no semánticos con manejadores. Un <div> con onClick no recibe foco con Tab, no responde a Enter ni a Espacio, y no se anuncia como botón. La solución es un <button>, siempre. Lo trabajaste en 06-03 y en 06-07.

2 · Foco perdido al actualizar. Es el problema 2 de 10-01, el que te llevó a escribir reconciliar. Cuando la clave es incorrecta o el contenido se recrea, el foco salta al principio. Quien navega con teclado o lector de pantalla se pierde; quien usa ratón no lo nota nunca. Que los tres frameworks resuelvan la reconciliación por defecto es, de hecho, una ventaja real de accesibilidad — siempre que uses la clave correcta.

3 · Cambios que no se anuncian. Al filtrar por Lucía, la lista pasa de 6 elementos a 1. Visualmente es obvio; para un lector de pantalla, no ha pasado nada. Hace falta una región activa:

Ese role="status" funciona igual en las cuatro versiones, porque es HTML, no framework.

4 · Navegación de SPA sin anuncio. En una navegación normal, el navegador anuncia la página nueva y mueve el foco. Con un enrutador de cliente no ocurre nada: la URL cambia y el contenido también, pero el lector de pantalla sigue donde estaba. Hay que mover el foco al encabezado principal y anunciar el cambio a mano.

Lo que sí ayudan los frameworks: componentes accesibles ya construidos —diálogos, menús, pestañas, combos— que implementan correctamente los patrones de ARIA, que es un trabajo difícil y fácil de hacer mal. Ahí el ecosistema pesa: hay bibliotecas de componentes sin estilos y accesibles para los tres.

La conclusión: la accesibilidad depende del HTML que produces y de las decisiones que tomas, no del framework. Exactamente igual que el SEO.

Cada año aparece algo nuevo, con demostraciones impresionantes y una comunidad entusiasta. Un método de cuatro pasos para evaluarlo sin dejarte llevar y sin ignorarlo por defecto.

Paso 1 · Lee la documentación, no los tuits. Concretamente, busca tres cosas: la guía de primeros pasos (¿en cuánto tiempo entiendes el modelo mental?), la guía de migración desde la versión anterior (¿cuánto cuesta actualizar?), y la sección de limitaciones o cuándo no usarlo. Un proyecto que documenta honestamente sus limitaciones es un proyecto maduro; uno que no las menciona todavía no ha chocado con ellas.

Paso 2 · Mira la cadencia de publicaciones y la política de versiones. Preguntas concretas y comprobables:

Paso 3 · Mide tu propio ejemplo. No el ejemplo de la portada, que está elegido para lucir: el tuyo. Coge la pantalla más representativa de tu aplicación, impleméntala y mide con las herramientas de 09-01: bytes descargados, tiempo hasta la primera pintura, INP al interactuar, nodos en el DOM. Es lo que has hecho en este módulo cuatro veces, y por eso la tabla del apartado 6 vale más que cualquier comparativa ajena.

Paso 4 · Haz el prototipo de un día. El apartado siguiente.

Es el consejo más rentable de esta lección, y el más ignorado.

Elige tu caso más difícil, no el más representativo. Nadie tiene problemas con la lista de tareas del tutorial. Los problemas están en lo raro: la tabla de 600 filas con filtro en vivo, el formulario con veinte campos condicionales, el editor colaborativo, la integración con esa librería antigua que no tiene tipos.

Para Nómada Tareas, el caso difícil está identificado desde 09-01: la lista virtualizada de 600 tareas con filtro en tiempo real y actualizaciones entrantes por WebSocket. Ahí es donde se ve si la herramienta sirve.

Cómo se hace, en un día:

Esa última hora es la más valiosa y la que siempre se salta. La lista de lo que no has sabido resolver en un día es la mejor predicción de lo que te costará durante un año.

Y una regla de oro: el prototipo se tira. No es el principio del proyecto, es un experimento. Si lo conviertes en la base del producto, habrás elegido tecnología con un código escrito con prisa y sin criterio.

Si ya tienes una aplicación funcionando —como Nómada Tareas— y decides cambiar, hay una tentación que casi siempre acaba mal: reescribirlo todo desde cero.

Por qué falla, con nombres concretos:

• Durante la reescritura, el producto no avanza. El negocio no se detiene y la presión crece.
• La versión antigua sigue necesitando correcciones, así que hay dos bases de código que mantener y sincronizar.
• Se subestima sistemáticamente la cantidad de reglas de negocio acumuladas en años de correcciones. Cada if raro que parece innecesario suele ser un error real que alguien arregló.
• El resultado más frecuente: seis meses después, una versión nueva incompleta y una vieja que sigue en producción.

Las tres estrategias que sí funcionan, en orden de granularidad:

Estrategia 1 · Migrar por rutas. La aplicación nueva y la vieja conviven, y un servidor o proxy decide qué versión sirve cada URL.

A favor: aislamiento total, cada pantalla se migra cuando toca, se puede parar en cualquier momento sin dejar nada a medias, y se aprende con una pantalla real antes de comprometerse. En contra: navegar entre pantallas de distinta generación implica una recarga completa; y hay que compartir sesión, estilos y estado entre las dos.

Estrategia 2 · Migrar por componentes. El framework nuevo se monta dentro de la aplicación existente, controlando un trozo de pantalla.

Recuerda que createRoot de 10-02 y createApp(...).mount('#id') de 10-04 hacen exactamente esto: toman un nodo del DOM y lo gobiernan, sin tocar el resto de la página. Vue está especialmente bien preparado para esto por su naturaleza progresiva.

A favor: la granularidad más fina posible, sin recargas, con resultados desde la primera semana. En contra: hay que comunicar dos mundos —los CustomEvent de 06-04 sirven perfectamente de puente— y durante un tiempo conviven dos motores en la misma página, con su coste de bytes.

Estrategia 3 · Por capas, empezando por abajo. A veces la migración correcta no es de la vista. Si tu problema es el estado y no el renderizado, se extrae primero el modelo a un almacén, se estabiliza, y solo después se cambia la vista. En Nómada Tareas esto ya está hecho: js/modelo/ y js/datos/ son independientes de la vista desde el principio, y esa es exactamente la razón por la que el fichero de dominio fue idéntico en las cuatro versiones.

Hay una cuarta opción que resuelve un problema específico: componentes que deben funcionar en cualquier sitio, incluida una aplicación de otra generación o de otro framework.

Los web components son estándar del navegador: customElements.define registra una etiqueta propia, el Shadow DOM aísla estilos de verdad, y el resultado es un elemento HTML normal que cualquier página puede usar.

Fíjate en lo que ya sabes hacer aquí: connectedCallback y disconnectedCallback son el ciclo de vida de 10-01, attachShadow es el scoped de Vue llevado al estándar, el CustomEvent con bubbles es tu mecanismo de 06-04, y el AbortController es tu limpieza de 09-03. Los web components son el ciclo de vida y el aislamiento sin framework.

El caso donde brillan y que conviene recordar: cuando dos partes de una organización usan tecnologías distintas y necesitan compartir componentes. Un sistema de diseño en web components lo consumen todos los equipos, hoy y cuando cambien de framework.

Aquí está el balance del curso entero, y merece una tabla:

Un dato de este módulo que sostiene la tabla mejor que cualquier argumento: el fichero dominio/reglas.js fue idéntico en las cuatro versiones de la pantalla. Las mismas cuarenta líneas —SIGUIENTE, ETIQUETA, PESOS, HOY, estaVencida— sirvieron sin cambiar una coma en JavaScript puro, en React, en Vue y en Angular. El 100 % del código que cambió fue vista.

Esa es la razón práctica de la disciplina que 10-01 recomendaba y que las cinco lecciones han repetido: mantén la lógica de negocio fuera del framework. No es purismo arquitectónico; es lo que hace que un cambio de framework sea reescribir la vista y no reescribir la aplicación.

Y hay una consecuencia personal, más allá del código. Lo que has aprendido en los nueve módulos anteriores no lo pierdes al cambiar de herramienta. Cuando aparezca el próximo framework —y aparecerá— no partirás de cero: sabrás qué problema dice resolver, con qué mecanismo, a cambio de qué, y podrás juzgarlo en una tarde. Esa capacidad es el activo, no la lista de herramientas que has usado.

Se dijo en 10-01 y se confirma aquí: el proyecto final se construye en JavaScript puro, con Nómada Tareas tal y como está.

Y ahora esa afirmación tiene una justificación que se puede defender con la tabla del apartado 3. Aplicándola al proyecto final del curso:

El resultado no es ambiguo: para este proyecto, en este contexto, JavaScript puro es la elección correcta. La aplicación ya existe, está medida, está probada con 124 pruebas y tres recorridos de extremo a extremo, tiene un service worker funcionando y un presupuesto de rendimiento en integración continua. Añadir un framework ahora no resolvería ningún problema que tengas y añadiría todos los costes de 10-01.

Lo que ha cambiado no es la tecnología: es que ahora sabes por qué. En el Módulo 1 usabas JavaScript puro porque era lo único que conocías. A partir de ahora lo usas porque, con los cuatro enfoques delante y las métricas medidas, es lo que corresponde a este caso. Y esa diferencia —entre hacer algo por desconocimiento y hacerlo por decisión— es, probablemente, lo más valioso que se lleva alguien de un módulo como este.

Elegir por comparativas de rendimiento. Las diferencias entre los grandes, en aplicaciones reales, son de milisegundos, y quedan sepultadas por cuántos datos pides, cuántas imágenes cargas y dónde renderizas. Optimizar la elección de framework por un banco de pruebas de 10.000 filas es optimizar una fila que no tienes.

Elegir por popularidad sin mirar el contexto local. «Es el más usado» es un dato global; tú contratas y trabajas en un mercado concreto. Mira ofertas reales de tu ciudad y de tu sector.

Ignorar lo que el equipo ya sabe. La productividad de un equipo experto en una herramienta supera casi siempre la de un equipo novato en otra objetivamente mejor. Cambiar de framework tiene un coste de aprendizaje que rara vez se presupuesta.

Confundir «no usar framework» con «no usar herramientas». Nómada Tareas tiene Vite, ESLint, Prettier, Jest y Cypress. La decisión de no usar un framework de componentes no implica renunciar a la cadena de herramientas.

Reescribir desde cero. Es la decisión que más proyectos ha hundido. Migra por rutas o por componentes, con la aplicación en producción todo el tiempo.

Olvidar la decisión de renderizado. Se discute durante semanas qué framework y se decide en diez minutos que será una SPA, cuando esa segunda decisión suele tener más impacto en el LCP, en el SEO y en la arquitectura.

Creer que el framework te da SEO o accesibilidad. No te los da ninguno. Te los da el HTML que produces, las URLs que diseñas, los <a href> reales, el foco que gestionas y las regiones activas que anuncias.

Meter la lógica de negocio en los componentes. Es el error que hace irreversible la elección. La prueba está en la mesa: 40 líneas de dominio idénticas en las cuatro versiones.

Evaluar solo con el ejemplo de la portada. Está elegido para lucir. Prototipa tu caso más difícil, y dedica la última hora a escribir lo que no has sabido resolver.

Consejo: escribe la decisión. Media página con el contexto, los criterios, los pesos y por qué. Dentro de dos años, cuando alguien pregunte «¿por qué usamos esto?», la respuesta existirá y podrá revisarse con datos nuevos.

Consejo: revisa la decisión cada cierto tiempo, sin cambiarla por costumbre. Los contextos cambian —el equipo crece, aparece un requisito de SEO, el proyecto se estabiliza— y una decisión correcta hace tres años puede no serlo hoy. Revisar no es migrar: es comprobar.

Consejo: aprende uno de verdad. Después de este módulo, elige uno y hazle un proyecto completo, con pruebas y despliegue. El modelo mental se transfiere; el dominio real, no.

Elige un proyecto real —tuyo, de tu trabajo, o uno que te gustaría hacer— y rellena la tabla del apartado 3 completa:

1. Describe el contexto en cinco líneas: qué es, quién lo usa, cuántas personas lo desarrollan, cuánto debe durar.
2. Asigna los pesos antes de puntuar, y justifica cada uno con una frase.
3. Puntúa las cuatro opciones, con una frase de justificación por celda.
4. Calcula los totales y léelos con criterio: ¿hay un ganador claro o hay empate? ¿Algún criterio con peso 5 descarta alguna opción por sí solo?
5. Escribe la decisión final en un párrafo, incluyendo qué coste estás aceptando.

Para cada uno de estos cuatro escenarios, decide el modo de renderizado (SPA, SSR, SSG o islas), nombra un meta-framework adecuado y justifica con al menos tres criterios de la lección. Indica también qué métrica de 09-01 sería la más importante de vigilar.

• (a) La web pública de Taller Nómada: quiénes somos, tarifas, galería, formulario de contacto y un calendario de disponibilidad que se actualiza cada hora. Debe posicionar bien. Una persona la mantiene tres horas al mes.
• (b) Nómada Tareas como producto para veinte talleres, detrás de un inicio de sesión, con edición colaborativa en tiempo real.
• (c) Una tienda en línea con 4.000 productos, precios que cambian a diario y reseñas de usuarios. El 70 % del tráfico llega desde buscadores.
• (d) La documentación pública de la API de Nómada Tareas: 120 páginas de texto y ejemplos de código, un buscador y un widget para probar las llamadas.

Taller Nómada decide, tres años después, migrar Nómada Tareas de JavaScript puro a un framework. La aplicación tiene entonces siete pantallas, 380 pruebas y tres personas trabajando en ella. No se puede parar el desarrollo de nuevas funcionalidades.

1. Elige la estrategia de migración y justifícala.
2. Escribe un plan de cinco fases, indicando en cada una qué se migra, qué queda igual y cómo se comprueba que nada se ha roto.
3. ¿Qué partes del código actual no habría que migrar en absoluto? Nómbralas concretamente.
4. ¿Qué harías con las 380 pruebas? Clasifícalas en las que se conservan tal cual, las que hay que adaptar y las que hay que reescribir.
5. Define tres criterios de parada: señales objetivas de que la migración va mal y hay que replantearla.

Solución 1

No hay solución única, pero sí una forma correcta y varias incorrectas. Un ejemplo trabajado, para calibrar:

Contexto. Panel interno de gestión de reservas para una cadena de cinco gimnasios. Lo usan doce recepcionistas durante toda su jornada. Lo desarrollan dos personas, una con experiencia en React y otra en JavaScript puro. Debe durar al menos cinco años. Está tras un inicio de sesión, en ordenadores de escritorio con buena conexión.

Pesos, con justificación:

Puntuaciones y total:

Lectura. React y Angular empatan (117 y 116), Vue queda a tres puntos y JavaScript puro está descartado. El desempate lo da un criterio que la tabla no puntúa pero que el enunciado sí menciona: una de las dos personas ya sabe React, y con un equipo de dos eso vale más que cualquier diferencia de tres puntos.

Decisión. React, con TypeScript desde el primer día (para compensar el punto débil frente a Angular en un proyecto de cinco años) y con una lista escrita de decisiones de ecosistema —enrutador, formularios, datos, estado— para mitigar la fragmentación con un equipo pequeño.

Coste aceptado. La fragmentación de React obliga a mantener nuestras propias convenciones y a actualizar seis dependencias de terceros durante cinco años, sin las migraciones automáticas de Angular. Se mitiga eligiendo librerías con mantenimiento demostrado y revisando las dependencias cada seis meses.

Lo que hace correcta esta solución no es el resultado, sino que los pesos se pusieron antes, cada celda tiene una razón, el empate se reconoce como empate y el coste se declara.

Solución 2

(a) Web pública de Taller Nómada → Estático con islas (Astro).

Criterios: el contenido cambia poquísimo y es igual para todos; el SEO es crítico y el HTML debe llegar completo; el mantenimiento es de tres horas al mes, así que la rotación del ecosistema es el riesgo dominante; y solo un elemento (el calendario) necesita interactividad y datos frescos.

Enfoque: las páginas se generan estáticamente y el calendario es una isla que carga su JavaScript al aparecer en pantalla, consultando la disponibilidad al cargarse. El formulario de contacto puede ser HTML nativo enviando a un endpoint, sin nada de JavaScript.

Métrica a vigilar: LCP, porque determina la primera impresión y es señal de posicionamiento. Con SSG debería estar cómodamente por debajo de 1 s.

(b) Nómada Tareas como producto → SPA.

Criterios: está tras un inicio de sesión, así que el SEO no aplica en absoluto; el contenido es distinto para cada usuario y no cacheable; la edición colaborativa exige estado en cliente y una conexión WebSocket permanente; y el patrón de uso es abrir la aplicación una vez y usarla durante horas, con lo que el coste de la primera carga se amortiza.

Enfoque: SPA pura, con división de código por rutas (09-05) para que la primera pantalla sea ligera.

Métrica a vigilar: INP, porque lo que decide la experiencia es la respuesta a cada interacción durante ocho horas, no el arranque. Es exactamente la fila que redujiste de 480 a 42 ms en el módulo 9.

(c) Tienda con 4.000 productos → SSR con caché, o estático con regeneración incremental.

Criterios: el 70 % del tráfico viene de buscadores, así que el HTML tiene que llegar completo y rápido; los precios cambian a diario, lo que descarta el estático puro sin regeneración; las reseñas son contenido generado por usuarios que debe indexarse; y 4.000 páginas hacen que una reconstrucción completa en cada cambio sea inviable.

Enfoque: Next.js o Nuxt con renderizado en servidor y caché por página, o generación estática con regeneración incremental para que solo se reconstruyan las fichas cuyo precio cambió.

Métrica a vigilar: LCP y, muy de cerca, CLS: las fichas de producto con imágenes y bloques de precio son donde más se descuidan las dimensiones reservadas, exactamente el problema que cerraste en 09-05.

(d) Documentación de la API → Estático (SSG) con dos islas.

Criterios: 120 páginas de texto que cambian con cada versión, iguales para todos; el SEO importa porque la gente llega buscando errores concretos; y solo dos cosas son interactivas: el buscador y el widget de pruebas.

Enfoque: SSG con un generador de documentación, buscador con índice generado en la compilación —cargado perezosamente al enfocar el campo de búsqueda— y el widget de pruebas como isla que solo carga al desplegarse.

Métrica a vigilar: el peso del JavaScript inicial. En documentación, la mayoría de las visitas leen una página y se van; cada kilobyte cargado que no se usa es puro desperdicio. Es la fila 10 de tu línea base de 09-01.

Solución 3

1 · Estrategia: migración por rutas, con componentes compartidos.

Justificación: con siete pantallas y tres personas que no pueden parar, la migración por rutas permite trabajar en una pantalla nueva mientras las demás siguen en producción sin tocarse, y da la posibilidad de parar en cualquier punto sin dejar nada a medias. La granularidad por componentes se reserva para dentro de una pantalla ya migrada.

2 · Plan de cinco fases:

La fase 2 tiene un objetivo que no es entregar valor: descubrir todos los problemas de integración —sesión compartida, estilos, cabecera común, navegación entre generaciones— con la pantalla que menos duele si sale mal.

3 · Qué NO habría que migrar:

• js/modelo/ completo: tarea.js, tablero.js, errores.js. Son JavaScript puro con las reglas R1–R10; se importan tal cual desde el framework nuevo.
• js/datos/http.js: pedirJson, ErrorDeApi y conReintentos de 07-03. Ningún framework mejora esto.
• js/util/: fechas.js, formato.js con Intl, tiempo.js con debounce, throttle y porLotes. Puro y reutilizable.
• js/datos/tiempo-real.js: el CanalTablero. La suscripción cambia de sitio, el canal no.
• sw.js y manifest.json: el service worker y la PWA de 07-05 son independientes del framework; solo hay que regenerar la lista de precaché.

Es, literalmente, la mayor parte del valor del proyecto. Lo que se migra es js/vista/.

4 · Las 380 pruebas:

Ese reparto —cerca del 85 % conservado o adaptado— es la mejor demostración del valor de las pruebas de integración por rol frente a las que se acoplan a detalles de implementación. Es exactamente lo que 08-05 defendía, cobrado tres años después.

5 · Tres criterios de parada:

1. La fase 2 tarda más del triple de lo estimado. Si migrar la pantalla más simple cuesta tres semanas en lugar de una, el problema no es la pantalla: es el acoplamiento oculto o la falta de dominio de la herramienta. Hay que parar y averiguar cuál de los dos.
2. El desarrollo de funcionalidades nuevas cae más de un 30 % durante dos meses seguidos. La migración debe convivir con el producto. Si lo devora, la estrategia por rutas no se está respetando.
3. Las métricas empeoran respecto a la línea base de 09-01 y no se recuperan en dos semanas. Si el LCP pasa de 1,9 a 3,5 s en la pantalla migrada y no baja, hay algo mal en la configuración o en el enfoque, y seguir migrando pantallas solo multiplica el problema.

Un cuarto criterio, informal pero muy fiable: si nadie del equipo puede explicar por qué se está migrando sin usar la palabra «moderno», la decisión no tenía criterio y conviene revisarla.

Has cerrado el módulo con lo que le daba sentido: el criterio para decidir.

Conoces los ocho criterios que importan —necesidades del producto, tamaño y experiencia del equipo, mercado laboral local, longevidad, rendimiento y SEO, accesibilidad, ecosistema y coste de contratación y formación— con la observación de que cinco de los ocho no son técnicos. Tienes la tabla de ponderación con sus tres reglas de uso: los pesos se ponen antes de puntuar, un peso de 5 puede vetar, y cada puntuación se justifica con una frase. Y sabes leerla con honestidad: sirve para descartar lo que no encaja y reconocer los empates, no para fabricar una precisión que no existe.

Tienes la comparativa técnica de los cuatro enfoques —modelo de reactividad, granularidad, inmutabilidad, curva, tamaño, opiniones, herramientas, tipado, pruebas, SSR, ecosistema, fragmentación, estado global, y dónde brilla y dónde estorba cada uno— con dos matices que evitan malentendidos: la fragmentación de React es un coste o una ventaja según el contexto, y el tamaño base importa mucho menos de lo que se dice salvo en widgets y sitios de contenido. Y tienes, sobre todo, las cuatro versiones de tu propia pantalla medidas: ~210 líneas y 18 kB en JavaScript puro con 60 líneas de infraestructura propia y riesgo alto de olvido; ~130 líneas y 63 kB en React; ~120 líneas y 53 kB en Vue; ~180 líneas y 85 kB en Angular con el fallo de la clave imposible por compilación. Con la conclusión que ninguna comparativa ajena podía darte: el framework compensa cuando mantener tu propia infraestructura cuesta más que descargar y aprender la suya, y ese punto llega antes con equipos grandes y mucho más tarde con una sola persona.

Sabes que hay una decisión que suele pesar más que la del framework: dónde se renderiza. Conoces la SPA con su primera carga lenta y su navegación instantánea; el SSR con su HTML completo, su hidratación y su servidor que mantener; el SSG como lo más rápido, barato y seguro que existe cuando el contenido no cambia por usuario; y las islas, que parten de la observación de que casi nada en una página necesita JavaScript —la misma idea de tu carga perezosa de 09-05 llevada a la arquitectura—. Tienes los meta-frameworks situados en una tabla, incluida la fila incómoda de htmx, que cuestiona la premisa entera y a veces tiene razón; y la regla de cinco filas que empareja tipo de contenido con modo de renderizado.

Sabes qué te da y qué no te da un framework en SEO —el HTML completo lo da el SSR, y el resto es tuyo: títulos, URLs, <a href> reales, semántica, datos estructurados, sitemap, imágenes y rendimiento— y en accesibilidad, donde la respuesta es más contundente: ninguno te salva de hacerlo mal, y de hecho los cuatro facilitan escribir un <div onClick> que funciona con ratón y con nada más. Con los cuatro fallos que se repiten y que ya sabes evitar: elementos no semánticos, foco perdido al actualizar, cambios que no se anuncian y navegación de SPA silenciosa.

Tienes un método para evaluar tecnología nueva: leer la documentación buscando las limitaciones declaradas, comprobar cadencia y política de versiones con seis preguntas concretas, medir tu propio ejemplo con las herramientas de 09-01, y hacer el prototipo de un día con el caso más difícil —no el más representativo— dedicando la última hora a escribir lo que no has sabido resolver, que es la mejor predicción de lo que costará durante un año. Y sabes que el prototipo se tira.

Conoces las estrategias de migración que funcionan —por rutas, por componentes montando el framework nuevo en un nodo de la página existente, y por capas empezando por abajo— frente a la reescritura total, que es la decisión que más proyectos ha hundido. Y sabes que los web components son la frontera cuando hace falta que algo funcione en cualquier sitio: connectedCallback y disconnectedCallback son el ciclo de vida de 10-01, attachShadow es el aislamiento de estilos llevado al estándar, y el CustomEvent con bubbles es tu mecanismo de 06-04 — todo sin framework y con la duración de la propia plataforma.

Y tienes el balance final, sostenido por un dato de este mismo módulo y no por una opinión: el fichero dominio/reglas.js fue idéntico en las cuatro versiones. Las mismas cuarenta líneas en JavaScript puro, React, Vue y Angular. Todo lo que cambió fue vista. Eso es lo que separa lo que no caduca —el lenguaje, el DOM, HTTP, las pruebas, el rendimiento, la accesibilidad, el modelo declarativo, saber modelar el estado y el criterio para decidir— de lo que sí: la sintaxis concreta, el nombre del hook, la librería de turno, los umbrales exactos.

Empieza ahora el Módulo 11, y el proyecto final se construye en JavaScript puro, con Nómada Tareas tal y como la has dejado: seis tareas y 48 horas en el tablero, sus reglas R1–R10, sus 124 pruebas y sus tres recorridos de extremo a extremo, su service worker, sus 58,3 kB en tres peticiones y su LCP de 1,9 segundos. Nada de eso cambia. Lo que ha cambiado es quién lo decide: en el Módulo 1 escribías JavaScript puro porque era lo único que sabías, y ahora lo escribes con React, Vue y Angular sobre la mesa, con las cuatro versiones de la misma pantalla medidas y con una tabla de ponderación que dice, para este proyecto y este contexto, que es la elección correcta. Esa es toda la diferencia entre un principiante y un profesional, y no está en la herramienta: un principiante usa lo que conoce; un profesional elige, sabe por qué, y puede defenderlo. Con esa capacidad —y con una aplicación que funciona, se prueba, se mide y se despliega— empieza lo último que queda: Configuración y Planificación del Proyecto.