Has escrit la mateixa pantalla de Nómada Tasques quatre vegades: en JavaScript pur, en React, en Vue i en Angular. Cada versió fa exactament el mateix —la llista de tasques, el filtre per responsable i el botó de marcar com a feta, amb els números canònics intactes— i cadascuna ho fa d'una manera diferent, amb costos diferents. Ara toca la pregunta que dona sentit a tot el mòdul i que cap tutorial no respon bé: com es tria. No amb una taula d'estrelles ni amb l'opinió d'una xerrada, sinó amb un mètode que puguis defensar davant del teu equip i davant de tu mateix d'aquí a tres anys. En aquesta lliçó veuràs els criteris que de debò importen —producte, equip, mercat laboral, longevitat, rendiment, SEO, accessibilitat, ecosistema i cost de contractació i formació— amb una taula de ponderació que pots omplir; la comparativa tècnica honesta dels quatre enfocaments en una taula de doble entrada; les quatre versions de la mateixa pantalla una al costat de l'altra amb les seves mètriques i una conclusió matisada; la decisió que acostuma a importar més que la del framework —on es renderitza: client, servidor, estàtic o híbrid, amb SPA, SSR, SSG i illes i els seus meta-frameworks—; els criteris de SEO i accessibilitat, i per què cap dels quatre no et salva de fer-ho malament; com avaluar una tecnologia nova sense caure en modes, amb el prototip d'un dia sobre el teu cas més difícil; i les estratègies de migració sense reescriptures totals. És l'última lliçó del mòdul, i tanca amb el que no caduca —el llenguatge, el DOM, HTTP, les proves, el rendiment: exactament el que has après— davant del que sí.

1. Per què existeix aquesta lliçó
2. Els criteris que importen
3. La taula de ponderació que pots omplir
4. Com es fa servir: la decisió de Taller Nómada, pas a pas
5. La comparativa tècnica honesta
6. Les quatre versions de la mateixa pantalla, amb mètriques
7. Què compensa segons el context
8. La decisió que acostuma a importar més: on es renderitza
9. SPA: renderitzat al client
10. SSR: renderitzat al servidor
11. SSG: generació estàtica
12. Illes i renderitzat híbrid
13. Els meta-frameworks en una taula
14. SEO: què et salva un framework i què no
15. Accessibilitat: cap no et salva de fer-ho malament
16. Com avaluar una tecnologia nova sense caure en modes
17. El prototip d'un dia amb el cas més difícil
18. Estratègies de migració sense reescriptures totals
19. Web components com a frontera
20. El que no caduca davant del que sí
21. El Mòdul 11: JavaScript pur, ara per decisió
22. Errors Habituals i Consells
23. Exercicis
24. Conclusió

Hi ha dues maneres de triar tecnologia, i totes dues es veuen cada dia.

La primera és la que domina: es tria el que es coneix, el que s'ha vist en una xerrada, el que fa servir l'empresa del costat, o el que apareix més vegades a les ofertes de feina. No és irracional —el mercat laboral és un criteri legítim, i el veurem— però s'aplica sense dir-ho, i per tant sense poder discutir-ho.

La segona és la que aprendràs aquí: enumerar els criteris, ponderar-los segons el context, mesurar el cas propi i decidir amb les dades al davant. No garanteix encertar; garanteix que la decisió es pugui explicar, revisar i corregir. I sobretot garanteix que sigui teva.

Un avís d'honestedat abans de començar, perquè aquesta lliçó no et donarà cap guanyador. Els quatre enfocaments que has vist són bons, i hi ha aplicacions excel·lents construïdes amb cadascun. Qualsevol text que et digui que un és objectivament superior està ignorant el context, que és exactament el que determina la resposta. El que sí que et puc donar és el mètode, les taules per aplicar-lo i les dades del teu propi projecte mesurat quatre vegades.

Vuit criteris, i cap no és «quin té millor rendiment en un banc de proves».

1 · Necessitats del producte. Quanta interactivitat té? Quantes pantalles? Hi ha formularis complexos, temps real, gràfics, edició col·laborativa? Un web amb un menú desplegable i una aplicació de gestió amb permisos per rol no són el mateix problema, encara que tots dos «siguin web».

2 · Mida i experiència de l'equip. Una persona sola optimitza per velocitat d'escriptura i poca cerimònia. Sis persones optimitzen per convencions compartides, contractes explícits i capacitat de revisar el codi aliè. I el que l'equip ja sap val més que qualsevol avantatge tècnic marginal: la productivitat d'un equip expert en una eina supera gairebé sempre la d'un equip novell en una altra de millor.

3 · Mercat laboral local. És un criteri incòmode però real, i funciona en dues direccions: si contractes, necessites trobar gent; si busques feina, necessites que la teva experiència sigui demandada on vius. I és local: les proporcions entre React, Vue i Angular varien molt entre països i entre sectors. Mira ofertes reals de la teva ciutat, no enquestes globals.

4 · Longevitat i estabilitat del projecte. Quant ha de durar això? Un projecte de tres mesos es pot permetre una tecnologia nova. Un que ha de funcionar deu anys sense que ningú el toqui ha d'apostar per estabilitat, política de versions clara i migracions automàtiques — o per no dependre de res.

5 · Requisits de rendiment i SEO. Quin és el teu pressupost de bytes? Els teus usuaris són a fibra o a 3G? El contingut s'ha d'indexar? Aquestes preguntes acostumen a decidir on es renderitza (apartat 8) abans que quin framework es fa servir.

6 · Accessibilitat. Hi ha obligació legal? Públic divers? Ús intensiu de teclat? Cap framework no te la dona feta, però alguns posen més fàcil fer-ho bé que d'altres.

7 · Ecosistema. Necessites una taula de dades avançada, un editor enriquit, gràfics complexos, un calendari? Com més específica sigui la necessitat, més pesa la mida de l'ecosistema.

8 · Cost de contractació i formació. Quant costa portar algú productiu i quant temps passa fins que ho és. Es mesura en setmanes, i es paga cada vegada que entra algú nou.

Fixa't en una cosa: cinc dels vuit no són tècnics. Aquesta proporció és representativa de com es prenen les decisions que surten bé.

El mètode és senzill. Per a cada criteri, assigna un pes d'1 a 5 segons el que importi en el teu context —no en abstracte—, puntua cada opció d'1 a 5, multiplica i suma.

Tres regles d'ús, sense les quals la taula és un adorn:

Regla 1 · Els pesos es posen abans de puntuar. Si decideixes els pesos després de veure les puntuacions, estàs justificant una decisió ja presa. És el biaix més comú i el més fàcil d'evitar.

Regla 2 · Un pes de 5 significa que pot vetar. Si el mercat laboral local pesa 5 i una opció treu 1, aquella opció està descartada encara que guanyi en total. Els criteris eliminatoris no es promitgen.

Regla 3 · Les puntuacions es justifiquen amb una frase. «React treu 4 en ecosistema perquè la taula de dades que necessitem existeix i està mantinguda.» Sense la frase, el número és una opinió disfressada de dada.

I un advertiment sobre l'instrument: la taula no decideix, ordena el pensament. Si el resultat t'incomoda, gairebé sempre significa que hi ha un criteri que no has escrit o un pes mal posat. Això també és informació valuosa.

Fem-ho amb un cas concret. La Marta vol convertir Nómada Tasques en un producte per a vint tallers de coworking: cinc pantalles, permisos per rol, informes, edició col·laborativa en temps real, un equip de quatre persones i un horitzó de cinc anys.

Pas 1 · Els pesos, amb la seva justificació:

Pas 2 · Les puntuacions, cadascuna amb la seva frase:

Algunes justificacions, perquè es vegi el raonament:

• JS pur treu 1 en «equip de quatre»: cada convenció s'hauria d'inventar, escriure i fer complir sense ajuda d'eines. És el problema 8 de 10-01, i amb quatre persones és car.
• JS pur treu 5 en longevitat: és l'únic que continuarà funcionant d'aquí a deu anys sense actualitzar res.
• Angular treu 5 en «equip de quatre»: convencions imposades, tipatge obligatori i contractes explícits són exactament el que necessita un equip que revisa el codi aliè.
• Angular treu 2 en formació: dues persones haurien d'aprendre TypeScript, decoradors, injecció de dependències, senyals i RxJS.
• JS pur treu 4 en accessibilitat: no perquè el framework la impedeixi, sinó perquè escriure l'HTML a mà fa més visible quins elements s'estan fent servir; amb un framework és més fàcil acabar amb un <div> amb onClick.

Pas 3 · Llegir el resultat amb criteri. Els tres frameworks són molt a prop (125, 131, 136) i JavaScript pur queda clarament descartat per a aquest cas. Una diferència d'onze punts sobre 130 no és una diferència: és dins del soroll de les puntuacions. La lectura correcta no és «guanya Angular», sinó:

Per a aquest context, qualsevol dels tres frameworks és una decisió defensable i JavaScript pur no ho és. L'elecció final s'ha de fer amb el criteri de desempat que la taula no captura: què coneix ja l'equip, i què es pot prototipar en un dia (apartat 17).

Aquest és l'ús honest d'una taula de ponderació: descartar el que no encaixa i reconèixer quan hi ha empat, no fabricar una precisió que no existeix.

Ara la taula de doble entrada dels quatre enfocaments, amb el que has vist a les cinc lliçons anteriors.

Dues files mereixen un comentari perquè acostumen a malinterpretar-se.

La de «fragmentació» de React no és només un defecte. Que hi hagi quatre encaminadors és un cost per a un equip petit que ha de triar, i un avantatge per a un que necessita alguna cosa que la solució oficial no cobreix. La mateixa característica es llegeix a l'inrevés segons el context.

La de «mida base» importa menys del que sembla. Quaranta kilobytes comprimits són uns 200 ms en una connexió dolenta, i acostumen a quedar sepultats per una sola imatge sense optimitzar o per una petició de dades lenta. Només és determinant en dos escenaris: widgets incrustats en pàgines alienes, i llocs de contingut on la majoria dels visitants veu una pàgina i se'n va.

I aquí hi ha el que fa aquesta lliçó diferent de qualsevol comparativa: les has escrit totes quatre. Aquestes són les dades de la mateixa pantalla —llista de tasques, filtre per responsable, botó d'avançar— amb el mateix backlog canònic de 6 tasques i els mateixos números de sortida.

Les xifres de pes i de primera pintura són ordres de magnitud mesurats en condicions equivalents, no marques absolutes: canvien amb la versió, amb la configuració de compilació i amb el que facis servir de cada framework. El que no canvia és la relació entre elles, que és el que interessa per decidir.

I ara la lectura honesta, columna a columna:

JavaScript pur guanya en pes, en peticions i en temps fins a la primera pintura. No és cap sorpresa: no hi ha cap motor per descarregar. També guanya en dependències, que és el criteri de longevitat. I perd estrepitosament en dues files: les 60 línies d'infraestructura que tu manteniu i proves —reconciliar, crearElement, $, $$, la delegació—, i el risc d'oblit en la neteja i en les claus, que són fallades reals que ja vas patir a 06-06 i a 09-03.

Vue té el millor equilibri en aquesta pantalla concreta: menys línies que cap, un sol fitxer per component amb estils aïllats, una dependència i el motor més lleuger dels tres.

React és molt a prop en línies i compra l'ecosistema més gran, a canvi de la memoïtzació manual que 10-02 obligava a discutir i d'un motor una mica més pesat.

Angular és el més verbós i el més pesat, i a canvi és l'únic on la fallada de la clau és impossible, el tipatge ve de sèrie i l'estat compartit no necessita cap decisió.

Una precisió important sobre les 40 línies de domini: són exactament el mateix fitxer a les quatre versions. SEGUENT, ETIQUETA, PESOS, AVUI, estaVencuda, horesObertes. Aquesta fila és la prova empírica de la disciplina que 10-01 recomanava: el framework s'endú la vista, no l'aplicació.

Amb les dades anteriors, la conclusió matisada:

I el criteri general que resumeix totes les files:

El framework compensa quan el cost de mantenir la teva pròpia infraestructura supera el cost de descarregar i aprendre la seva. Aquest punt arriba abans del que la gent es pensa amb equips grans, i molt més tard del que la gent es pensa amb una sola persona.

Aquí hi ha l'afirmació més útil de tota la lliçó, i la que més gent descobreix tard:

On es renderitza el teu HTML afecta més el rendiment percebut, el SEO i l'arquitectura que quin framework facis servir.

La raó és aritmètica. Canviar de React a Vue t'estalvia uns 10 kB i alguns mil·lisegons d'actualització. Canviar de renderitzat al client a renderitzat al servidor o estàtic pot portar-te d'1,9 s de LCP a 0,6 s, i de «Google veu una pàgina buida» a «Google veu el contingut complet». És un ordre de magnitud més d'impacte, i tanmateix es discuteix moltíssim menys.

Els quatre enfocaments, amb el mateix esquema per poder comparar-los:

És el que has fet tot el curs i el que fan les quatre versions de la pantalla. El servidor envia un HTML gairebé buit i el JavaScript construeix la interfície.

A favor: navegació instantània entre pantalles un cop carregat; interaccions molt riques sense anar al servidor; desplegament senzill (fitxers estàtics); i una separació neta entre frontend i API.

En contra: la primera càrrega és la més lenta de les quatre —cal descarregar, analitzar, executar, demanar dades i pintar, en cadena—; l'HTML inicial és buit, cosa que perjudica el SEO i qualsevol cosa que llegeixi la pàgina sense executar JavaScript; i si el JavaScript falla, no hi ha res.

Quan és el correcte: aplicacions darrere d'un inici de sessió, eines internes, plafons de dades, editors. Tot allò on el SEO no importa i on l'usuari obre l'aplicació una vegada i la fa servir durant hores — que és exactament el cas de Nómada Tasques.

El servidor executa els components i envia HTML ja pintat. El navegador el mostra de seguida i després descarrega el JavaScript per hidratar la pàgina: adjuntar els gestors d'esdeveniments i recuperar l'estat, convertint l'HTML estàtic en l'aplicació interactiva.

A favor: el contingut és visible molt abans (millor LCP i FCP); l'HTML és complet des del primer byte, així que cercadors i previsualitzacions el veuen; funciona en dispositius lents, on el cost és executar JavaScript.

En contra: necessites un servidor executant Node.js, amb el seu cost, el seu escalat i el seu manteniment; el TTFB empitjora, perquè el servidor ha de treballar abans de respondre; la hidratació té un cost real i produeix l'efecte incòmode d'una pàgina que es veu però encara no respon; i el codi ha de funcionar als dos entorns, cosa que obliga a vigilar qualsevol ús de window o document.

Quan és el correcte: comerç electrònic, mitjans, qualsevol producte on el contingut s'hagi d'indexar i on la primera impressió determini si l'usuari es queda.

L'HTML es genera durant la compilació, una sola vegada, i se serveix des d'una CDN com a fitxers estàtics.

A favor: és el més ràpid que existeix —el servidor no calcula res, només lliura un fitxer des del node més proper—; és el més barat d'allotjar; és el més segur (no hi ha servidor per atacar); i és el més fiable.

En contra: només serveix per a contingut que no canvia per usuari ni per petició; amb milers de pàgines, la compilació es torna lenta; i publicar un canvi requereix reconstruir, encara que la regeneració incremental ho mitigui reconstruint només el que ha canviat.

Quan és el correcte: documentació, blogs, webs de producte, portafolis, catàlegs que canvien poques vegades al dia. I sí: el web públic de Taller Nómada hi encaixa perfectament.

L'arquitectura d'illes parteix d'una observació incòmoda: a la majoria de les pàgines, gairebé res no necessita JavaScript. Un article, una fitxa de producte o una pàgina de tarifes són text i imatges; només el cercador, la cistella o el calendari són interactius.

La idea: generar HTML estàtic per a tota la pàgina i carregar JavaScript només per als trossos interactius, cadascun independent, cadascun hidratant-se quan calgui —en aparèixer a la pantalla, en interactuar, o mai.

El resultat és que una pàgina amb tres widgets descarrega el JavaScript d'aquells tres widgets, no el de la pàgina sencera. I els widgets poden estar escrits en frameworks diferents, perquè cada illa és independent.

Si això et sona, és perquè ja ho vas fer: el @defer (on viewport) d'Angular a 10-05 i la teva càrrega diferida amb IntersectionObserver de 09-05 són la mateixa idea aplicada dins d'una aplicació. Les illes l'apliquen a l'arquitectura sencera.

Quan és el correcte: llocs de contingut amb interactivitat puntual. És el punt òptim del web públic modern, i la raó que aquest enfocament hagi crescut tant.

Un meta-framework és una capa per sobre del framework de components que aporta encaminament per fitxers, renderitzat al servidor o estàtic, optimització de la compilació i desplegament.

L'última fila mereix atenció, encara que sembli marginal. htmx qüestiona la premissa sencera del mòdul: en lloc de construir la interfície al navegador amb estat local, el servidor retorna HTML i el client l'insereix on toca. Per a aplicacions de tipus formulari-i-llista —que són moltíssimes— funciona sorprenentment bé i elimina de cop la sincronització d'estat entre client i servidor, que és el problema 15 de 10-01. No és la resposta per a un editor col·laboratiu, però és una resposta legítima que convé tenir al mapa.

I la regla pràctica per triar mode de renderitzat, que és més simple del que sembla:

Els cercadors moderns executen JavaScript, però amb matisos que fan que confiar-s'hi surti car:

• La indexació de contingut renderitzat al client es pot endarrerir dies respecte a la de l'HTML directe, perquè requereix una segona passada amb més recursos.
• Altres rastrejadors —xarxes socials per a les previsualitzacions, agregadors, eines d'anàlisi, alguns cercadors— no executen JavaScript en absolut.
• Les Core Web Vitals que vas mesurar a 09-01 (LCP, INP, CLS) són senyals de posicionament, i una SPA parteix amb desavantatge en LCP.

El que un framework et dona: res per si mateix. El que et dona un meta-framework amb SSR o SSG: HTML complet a la primera resposta, que és la meitat del problema.

I el que cap framework no et dona, i continua sent responsabilitat teva:

Fixa't que la major part d'aquesta taula és HTML i decisions d'arquitectura, no framework. És el mateix missatge de l'apartat 20.

Aquí convé ser taxatiu, perquè és el punt on més mal fa la falsa sensació de seguretat.

Cap framework no fa la teva aplicació accessible. Al contrari: els frameworks faciliten escriure coses inaccessibles, perquè fan igual de fàcil escriure <button> que <div onClick>, i el segon funciona amb ratolí perfectament.

Les quatre fallades que es repeteixen en aplicacions construïdes amb framework, i que ja saps evitar:

1 · Elements no semàntics amb gestors. Un <div> amb onClick no rep focus amb Tab, no respon a Enter ni a Espai, i no s'anuncia com a botó. La solució és un <button>, sempre. Ho vas treballar a 06-03 i a 06-07.

2 · Focus perdut en actualitzar. És el problema 2 de 10-01, el que et va portar a escriure reconciliar. Quan la clau és incorrecta o el contingut es recrea, el focus salta al principi. Qui navega amb teclat o lector de pantalla es perd; qui fa servir ratolí no ho nota mai. Que els tres frameworks resolguin la reconciliació per defecte és, de fet, un avantatge real d'accessibilitat — sempre que facis servir la clau correcta.

3 · Canvis que no s'anuncien. En filtrar per Lucía, la llista passa de 6 elements a 1. Visualment és obvi; per a un lector de pantalla, no ha passat res. Cal una regió activa:

Aquest role="status" funciona igual a les quatre versions, perquè és HTML, no framework.

4 · Navegació de SPA sense anunci. En una navegació normal, el navegador anuncia la pàgina nova i mou el focus. Amb un encaminador de client no passa res: l'URL canvia i el contingut també, però el lector de pantalla continua on era. Cal moure el focus a l'encapçalament principal i anunciar el canvi a mà.

El que sí que ajuden els frameworks: components accessibles ja construïts —diàlegs, menús, pestanyes, combos— que implementen correctament els patrons d'ARIA, que és una feina difícil i fàcil de fer malament. Aquí l'ecosistema pesa: hi ha biblioteques de components sense estils i accessibles per als tres.

La conclusió: l'accessibilitat depèn de l'HTML que produeixes i de les decisions que prens, no del framework. Exactament igual que el SEO.

Cada any apareix alguna cosa nova, amb demostracions impressionants i una comunitat entusiasta. Un mètode de quatre passos per avaluar-la sense deixar-te endur i sense ignorar-la per defecte.

Pas 1 · Llegeix la documentació, no els tuits. Concretament, busca tres coses: la guia de primeres passes (en quant de temps entens el model mental?), la guia de migració des de la versió anterior (quant costa actualitzar?), i la secció de limitacions o quan no fer-lo servir. Un projecte que documenta honestament les seves limitacions és un projecte madur; un que no les esmenta encara no hi ha topat.

Pas 2 · Mira la cadència de publicacions i la política de versions. Preguntes concretes i comprovables:

Pas 3 · Mesura el teu propi exemple. No l'exemple de la portada, que està triat per lluir: el teu. Agafa la pantalla més representativa de la teva aplicació, implementa-la i mesura amb les eines de 09-01: bytes descarregats, temps fins a la primera pintura, INP en interactuar, nodes al DOM. És el que has fet en aquest mòdul quatre vegades, i per això la taula de l'apartat 6 val més que qualsevol comparativa aliena.

Pas 4 · Fes el prototip d'un dia. L'apartat següent.

És el consell més rendible d'aquesta lliçó, i el més ignorat.

Tria el teu cas més difícil, no el més representatiu. Ningú no té problemes amb la llista de tasques del tutorial. Els problemes són en el que és estrany: la taula de 600 files amb filtre en viu, el formulari amb vint camps condicionals, l'editor col·laboratiu, la integració amb aquella llibreria antiga que no té tipus.

Per a Nómada Tasques, el cas difícil està identificat des de 09-01: la llista virtualitzada de 600 tasques amb filtre en temps real i actualitzacions entrants per WebSocket. Allà és on es veu si l'eina serveix.

Com es fa, en un dia:

Aquesta última hora és la més valuosa i la que sempre se salta. La llista del que no has sabut resoldre en un dia és la millor predicció del que et costarà durant un any.

I una regla d'or: el prototip es llença. No és el principi del projecte, és un experiment. Si el converteixes en la base del producte, hauràs triat tecnologia amb un codi escrit amb pressa i sense criteri.

Si ja tens una aplicació funcionant —com Nómada Tasques— i decideixes canviar, hi ha una temptació que gairebé sempre acaba malament: reescriure-ho tot des de zero.

Per què falla, amb noms concrets:

• Durant la reescriptura, el producte no avança. El negoci no s'atura i la pressió creix.
• La versió antiga continua necessitant correccions, així que hi ha dues bases de codi per mantenir i sincronitzar.
• Se subestima sistemàticament la quantitat de regles de negoci acumulades en anys de correccions. Cada if estrany que sembla innecessari acostuma a ser un error real que algú va arreglar.
• El resultat més freqüent: sis mesos després, una versió nova incompleta i una de vella que continua en producció.

Les tres estratègies que sí que funcionen, en ordre de granularitat:

Estratègia 1 · Migrar per rutes. L'aplicació nova i la vella conviuen, i un servidor o proxy decideix quina versió serveix cada URL.

A favor: aïllament total, cada pantalla es migra quan toca, es pot aturar en qualsevol moment sense deixar res a mitges, i s'aprèn amb una pantalla real abans de comprometre's. En contra: navegar entre pantalles de generació diferent implica una recàrrega completa; i cal compartir sessió, estils i estat entre les dues.

Estratègia 2 · Migrar per components. El framework nou es munta dins de l'aplicació existent, controlant un tros de pantalla.

Recorda que createRoot de 10-02 i createApp(...).mount('#id') de 10-04 fan exactament això: prenen un node del DOM i el governen, sense tocar la resta de la pàgina. Vue està especialment ben preparat per a això per la seva naturalesa progressiva.

A favor: la granularitat més fina possible, sense recàrregues, amb resultats des de la primera setmana. En contra: cal comunicar dos mons —els CustomEvent de 06-04 serveixen perfectament de pont— i durant un temps conviuen dos motors a la mateixa pàgina, amb el seu cost de bytes.

Estratègia 3 · Per capes, començant per baix. De vegades la migració correcta no és de la vista. Si el teu problema és l'estat i no el renderitzat, s'extreu primer el model a un magatzem, s'estabilitza, i només després es canvia la vista. A Nómada Tasques això ja està fet: js/model/ i js/dades/ són independents de la vista des del principi, i aquesta és exactament la raó per la qual el fitxer de domini va ser idèntic a les quatre versions.

Hi ha una quarta opció que resol un problema específic: components que han de funcionar a qualsevol lloc, inclosa una aplicació d'una altra generació o d'un altre framework.

Els web components són estàndard del navegador: customElements.define registra una etiqueta pròpia, el Shadow DOM aïlla estils de debò, i el resultat és un element HTML normal que qualsevol pàgina pot fer servir.

Fixa't en el que ja saps fer aquí: connectedCallback i disconnectedCallback són el cicle de vida de 10-01, attachShadow és el scoped de Vue portat a l'estàndard, el CustomEvent amb bubbles és el teu mecanisme de 06-04, i l'AbortController és la teva neteja de 09-03. Els web components són el cicle de vida i l'aïllament sense framework.

El cas on llueixen i que convé recordar: quan dues parts d'una organització fan servir tecnologies diferents i necessiten compartir components. Un sistema de disseny en web components el consumeixen tots els equips, avui i quan canviïn de framework.

Aquí hi ha el balanç del curs sencer, i mereix una taula:

Una dada d'aquest mòdul que sosté la taula millor que qualsevol argument: el fitxer domini/regles.js va ser idèntic a les quatre versions de la pantalla. Les mateixes quaranta línies —SEGUENT, ETIQUETA, PESOS, AVUI, estaVencuda— van servir sense canviar-hi una coma en JavaScript pur, en React, en Vue i en Angular. El 100 % del codi que va canviar va ser vista.

Aquesta és la raó pràctica de la disciplina que 10-01 recomanava i que les cinc lliçons han repetit: mantén la lògica de negoci fora del framework. No és purisme arquitectònic; és el que fa que un canvi de framework sigui reescriure la vista i no reescriure l'aplicació.

I hi ha una conseqüència personal, més enllà del codi. El que has après als nou mòduls anteriors no ho perds en canviar d'eina. Quan aparegui el pròxim framework —i apareixerà— no partiràs de zero: sabràs quin problema diu que resol, amb quin mecanisme, a canvi de què, i el podràs jutjar en una tarda. Aquesta capacitat és l'actiu, no la llista d'eines que has fet servir.

Es va dir a 10-01 i es confirma aquí: el projecte final es construeix en JavaScript pur, amb Nómada Tasques tal com està.

I ara aquesta afirmació té una justificació que es pot defensar amb la taula de l'apartat 3. Aplicant-la al projecte final del curs:

El resultat no és ambigu: per a aquest projecte, en aquest context, JavaScript pur és l'elecció correcta. L'aplicació ja existeix, està mesurada, està provada amb 124 proves i tres recorreguts d'extrem a extrem, té un service worker funcionant i un pressupost de rendiment en integració contínua. Afegir-hi un framework ara no resoldria cap problema que tinguis i afegiria tots els costos de 10-01.

El que ha canviat no és la tecnologia: és que ara saps per què. Al Mòdul 1 feies servir JavaScript pur perquè era l'únic que coneixies. A partir d'ara el fas servir perquè, amb els quatre enfocaments al davant i les mètriques mesurades, és el que correspon a aquest cas. I aquesta diferència —entre fer una cosa per desconeixement i fer-la per decisió— és, probablement, el més valuós que s'emporta algú d'un mòdul com aquest.

Triar per comparatives de rendiment. Les diferències entre els grans, en aplicacions reals, són de mil·lisegons, i queden sepultades per quantes dades demanes, quantes imatges carregues i on renderitzes. Optimitzar l'elecció de framework per un banc de proves de 10.000 files és optimitzar una fila que no tens.

Triar per popularitat sense mirar el context local. «És el més usat» és una dada global; tu contractes i treballes en un mercat concret. Mira ofertes reals de la teva ciutat i del teu sector.

Ignorar el que l'equip ja sap. La productivitat d'un equip expert en una eina supera gairebé sempre la d'un equip novell en una altra objectivament millor. Canviar de framework té un cost d'aprenentatge que poques vegades es pressuposta.

Confondre «no fer servir framework» amb «no fer servir eines». Nómada Tasques té Vite, ESLint, Prettier, Jest i Cypress. La decisió de no fer servir un framework de components no implica renunciar a la cadena d'eines.

Reescriure des de zero. És la decisió que més projectes ha enfonsat. Migra per rutes o per components, amb l'aplicació en producció tota l'estona.

Oblidar la decisió de renderitzat. Es discuteix durant setmanes quin framework i es decideix en deu minuts que serà una SPA, quan aquesta segona decisió acostuma a tenir més impacte en el LCP, en el SEO i en l'arquitectura.

Creure que el framework et dona SEO o accessibilitat. No te'ls dona cap. Te'ls dona l'HTML que produeixes, les URL que dissenyes, els <a href> reals, el focus que gestiones i les regions actives que anuncies.

Ficar la lògica de negoci als components. És l'error que fa irreversible l'elecció. La prova és a la taula: 40 línies de domini idèntiques a les quatre versions.

Avaluar només amb l'exemple de la portada. Està triat per lluir. Prototipa el teu cas més difícil, i dedica l'última hora a escriure el que no has sabut resoldre.

Consell: escriu la decisió. Mitja pàgina amb el context, els criteris, els pesos i el perquè. D'aquí a dos anys, quan algú pregunti «per què fem servir això?», la resposta existirà i es podrà revisar amb dades noves.

Consell: revisa la decisió de tant en tant, sense canviar-la per costum. Els contextos canvien —l'equip creix, apareix un requisit de SEO, el projecte s'estabilitza— i una decisió correcta fa tres anys pot no ser-ho avui. Revisar no és migrar: és comprovar.

Consell: aprèn-ne un de debò. Després d'aquest mòdul, tria'n un i fes-li un projecte complet, amb proves i desplegament. El model mental es transfereix; el domini real, no.

Tria un projecte real —teu, de la teva feina, o un que t'agradaria fer— i omple la taula de l'apartat 3 sencera:

1. Descriu el context en cinc línies: què és, qui el fa servir, quantes persones el desenvolupen, quant ha de durar.
2. Assigna els pesos abans de puntuar, i justifica cadascun amb una frase.
3. Puntua les quatre opcions, amb una frase de justificació per cel·la.
4. Calcula els totals i llegeix-los amb criteri: hi ha un guanyador clar o hi ha empat? Algun criteri amb pes 5 descarta alguna opció per si sol?
5. Escriu la decisió final en un paràgraf, incloent-hi quin cost estàs acceptant.

Per a cadascun d'aquests quatre escenaris, decideix el mode de renderitzat (SPA, SSR, SSG o illes), anomena un meta-framework adequat i justifica-ho amb almenys tres criteris de la lliçó. Indica també quina mètrica de 09-01 seria la més important de vigilar.

• (a) El web públic de Taller Nómada: qui som, tarifes, galeria, formulari de contacte i un calendari de disponibilitat que s'actualitza cada hora. Ha de posicionar bé. Una persona el manté tres hores al mes.
• (b) Nómada Tasques com a producte per a vint tallers, darrere d'un inici de sessió, amb edició col·laborativa en temps real.
• (c) Una botiga en línia amb 4.000 productes, preus que canvien cada dia i ressenyes d'usuaris. El 70 % del trànsit arriba des de cercadors.
• (d) La documentació pública de l'API de Nómada Tasques: 120 pàgines de text i exemples de codi, un cercador i un widget per provar les crides.

Taller Nómada decideix, tres anys després, migrar Nómada Tasques de JavaScript pur a un framework. L'aplicació té llavors set pantalles, 380 proves i tres persones treballant-hi. No es pot aturar el desenvolupament de noves funcionalitats.

1. Tria l'estratègia de migració i justifica-la.
2. Escriu un pla de cinc fases, indicant a cadascuna què es migra, què queda igual i com es comprova que res no s'ha trencat.
3. Quines parts del codi actual no caldria migrar en absolut? Anomena-les concretament.
4. Què faries amb les 380 proves? Classifica-les en les que es conserven tal qual, les que cal adaptar i les que cal reescriure.
5. Defineix tres criteris d'aturada: senyals objectius que la migració va malament i cal replantejar-la.

Solució 1

No hi ha una solució única, però sí una forma correcta i unes quantes d'incorrectes. Un exemple treballat, per calibrar:

Context. Plafó intern de gestió de reserves per a una cadena de cinc gimnasos. El fan servir dotze recepcionistes durant tota la jornada. El desenvolupen dues persones, una amb experiència en React i una altra en JavaScript pur. Ha de durar almenys cinc anys. És darrere d'un inici de sessió, en ordinadors d'escriptori amb bona connexió.

Pesos, amb justificació:

Puntuacions i total:

Lectura. React i Angular empaten (117 i 116), Vue queda a tres punts i JavaScript pur està descartat. El desempat el dona un criteri que la taula no puntua però que l'enunciat sí que esmenta: una de les dues persones ja sap React, i amb un equip de dues això val més que qualsevol diferència de tres punts.

Decisió. React, amb TypeScript des del primer dia (per compensar el punt feble davant d'Angular en un projecte de cinc anys) i amb una llista escrita de decisions d'ecosistema —encaminador, formularis, dades, estat— per mitigar la fragmentació amb un equip petit.

Cost acceptat. La fragmentació de React obliga a mantenir les nostres pròpies convencions i a actualitzar sis dependències de tercers durant cinc anys, sense les migracions automàtiques d'Angular. Es mitiga triant llibreries amb manteniment demostrat i revisant les dependències cada sis mesos.

El que fa correcta aquesta solució no és el resultat, sinó que els pesos es van posar abans, cada cel·la té una raó, l'empat es reconeix com a empat i el cost es declara.

Solució 2

(a) Web públic de Taller Nómada → Estàtic amb illes (Astro).

Criteris: el contingut canvia poquíssim i és igual per a tothom; el SEO és crític i l'HTML ha d'arribar complet; el manteniment és de tres hores al mes, així que la rotació de l'ecosistema és el risc dominant; i només un element (el calendari) necessita interactivitat i dades fresques.

Enfocament: les pàgines es generen estàticament i el calendari és una illa que carrega el seu JavaScript en aparèixer a la pantalla, consultant la disponibilitat en carregar-se. El formulari de contacte pot ser HTML natiu enviant a un endpoint, sense gens de JavaScript.

Mètrica a vigilar: LCP, perquè determina la primera impressió i és senyal de posicionament. Amb SSG hauria d'estar còmodament per sota d'1 s.

(b) Nómada Tasques com a producte → SPA.

Criteris: és darrere d'un inici de sessió, així que el SEO no s'hi aplica en absolut; el contingut és diferent per a cada usuari i no cachejable; l'edició col·laborativa exigeix estat al client i una connexió WebSocket permanent; i el patró d'ús és obrir l'aplicació una vegada i fer-la servir durant hores, amb la qual cosa el cost de la primera càrrega s'amortitza.

Enfocament: SPA pura, amb divisió de codi per rutes (09-05) perquè la primera pantalla sigui lleugera.

Mètrica a vigilar: INP, perquè el que decideix l'experiència és la resposta a cada interacció durant vuit hores, no l'arrencada. És exactament la fila que vas reduir de 480 a 42 ms al mòdul 9.

(c) Botiga amb 4.000 productes → SSR amb memòria cau, o estàtic amb regeneració incremental.

Criteris: el 70 % del trànsit ve de cercadors, així que l'HTML ha d'arribar complet i ràpid; els preus canvien cada dia, cosa que descarta l'estàtic pur sense regeneració; les ressenyes són contingut generat per usuaris que s'ha d'indexar; i 4.000 pàgines fan que una reconstrucció completa a cada canvi sigui inviable.

Enfocament: Next.js o Nuxt amb renderitzat al servidor i memòria cau per pàgina, o generació estàtica amb regeneració incremental perquè només es reconstrueixin les fitxes el preu de les quals ha canviat.

Mètrica a vigilar: LCP i, molt de prop, CLS: les fitxes de producte amb imatges i blocs de preu són on més es descuiden les dimensions reservades, exactament el problema que vas tancar a 09-05.

(d) Documentació de l'API → Estàtic (SSG) amb dues illes.

Criteris: 120 pàgines de text que canvien amb cada versió, iguals per a tothom; el SEO importa perquè la gent hi arriba cercant errors concrets; i només dues coses són interactives: el cercador i el widget de proves.

Enfocament: SSG amb un generador de documentació, cercador amb índex generat a la compilació —carregat de manera diferida en enfocar el camp de cerca— i el widget de proves com a illa que només carrega en desplegar-se.

Mètrica a vigilar: el pes del JavaScript inicial. En documentació, la majoria de les visites llegeixen una pàgina i se'n van; cada kilobyte carregat que no es fa servir és pur malbaratament. És la fila 10 de la teva línia base de 09-01.

Solució 3

1 · Estratègia: migració per rutes, amb components compartits.

Justificació: amb set pantalles i tres persones que no poden aturar-se, la migració per rutes permet treballar en una pantalla nova mentre les altres continuen en producció sense tocar-les, i dona la possibilitat d'aturar-se en qualsevol punt sense deixar res a mitges. La granularitat per components es reserva per a dins d'una pantalla ja migrada.

2 · Pla de cinc fases:

La fase 2 té un objectiu que no és lliurar valor: descobrir tots els problemes d'integració —sessió compartida, estils, capçalera comuna, navegació entre generacions— amb la pantalla que menys dol si surt malament.

3 · Què NO caldria migrar:

• js/model/ sencer: tasca.js, tauler.js, errors.js. Són JavaScript pur amb les regles R1–R10; s'importen tal qual des del framework nou.
• js/dades/http.js: demanarJson, ErrorDeApi i ambReintents de 07-03. Cap framework no millora això.
• js/util/: dates.js, format.js amb Intl, temps.js amb debounce, throttle i perLots. Pur i reutilitzable.
• js/dades/temps-real.js: el CanalTauler. La subscripció canvia de lloc, el canal no.
• sw.js i manifest.json: el service worker i la PWA de 07-05 són independents del framework; només cal regenerar la llista de precaché.

És, literalment, la major part del valor del projecte. El que es migra és js/vista/.

4 · Les 380 proves:

Aquest repartiment —prop del 85 % conservat o adaptat— és la millor demostració del valor de les proves d'integració per rol davant de les que s'acoblen a detalls d'implementació. És exactament el que 08-05 defensava, cobrat tres anys després.

5 · Tres criteris d'aturada:

1. La fase 2 triga més del triple de l'estimat. Si migrar la pantalla més simple costa tres setmanes en lloc d'una, el problema no és la pantalla: és l'acoblament ocult o la manca de domini de l'eina. Cal aturar-se i esbrinar quin dels dos.
2. El desenvolupament de funcionalitats noves cau més d'un 30 % durant dos mesos seguits. La migració ha de conviure amb el producte. Si se'l menja, l'estratègia per rutes no s'està respectant.
3. Les mètriques empitjoren respecte a la línia base de 09-01 i no es recuperen en dues setmanes. Si el LCP passa d'1,9 a 3,5 s a la pantalla migrada i no baixa, hi ha alguna cosa malament a la configuració o a l'enfocament, i continuar migrant pantalles només multiplica el problema.

Un quart criteri, informal però molt fiable: si ningú de l'equip no pot explicar per què s'està migrant sense fer servir la paraula «modern», la decisió no tenia criteri i convé revisar-la.

Has tancat el mòdul amb el que li donava sentit: el criteri per decidir.

Coneixes els vuit criteris que importen —necessitats del producte, mida i experiència de l'equip, mercat laboral local, longevitat, rendiment i SEO, accessibilitat, ecosistema i cost de contractació i formació— amb l'observació que cinc dels vuit no són tècnics. Tens la taula de ponderació amb les seves tres regles d'ús: els pesos es posen abans de puntuar, un pes de 5 pot vetar, i cada puntuació es justifica amb una frase. I saps llegir-la amb honestedat: serveix per descartar el que no encaixa i reconèixer els empats, no per fabricar una precisió que no existeix.

Tens la comparativa tècnica dels quatre enfocaments —model de reactivitat, granularitat, immutabilitat, corba, mida, opinions, eines, tipatge, proves, SSR, ecosistema, fragmentació, estat global, i on llueix i on fa nosa cadascun— amb dos matisos que eviten malentesos: la fragmentació de React és un cost o un avantatge segons el context, i la mida base importa molt menys del que es diu tret de widgets i llocs de contingut. I tens, sobretot, les quatre versions de la teva pròpia pantalla mesurades: ~210 línies i 18 kB en JavaScript pur amb 60 línies d'infraestructura pròpia i risc alt d'oblit; ~130 línies i 63 kB en React; ~120 línies i 53 kB en Vue; ~180 línies i 85 kB en Angular amb la fallada de la clau impossible per compilació. Amb la conclusió que cap comparativa aliena no podia donar-te: el framework compensa quan mantenir la teva pròpia infraestructura costa més que descarregar i aprendre la seva, i aquest punt arriba abans amb equips grans i molt més tard amb una sola persona.

Saps que hi ha una decisió que acostuma a pesar més que la del framework: on es renderitza. Coneixes la SPA amb la seva primera càrrega lenta i la seva navegació instantània; el SSR amb el seu HTML complet, la seva hidratació i el seu servidor per mantenir; el SSG com el més ràpid, barat i segur que existeix quan el contingut no canvia per usuari; i les illes, que parteixen de l'observació que gairebé res en una pàgina no necessita JavaScript —la mateixa idea de la teva càrrega diferida de 09-05 portada a l'arquitectura—. Tens els meta-frameworks situats en una taula, inclosa la fila incòmoda d'htmx, que qüestiona la premissa sencera i de vegades té raó; i la regla de cinc files que aparella tipus de contingut amb mode de renderitzat.

Saps què et dona i què no et dona un framework en SEO —l'HTML complet el dona el SSR, i la resta és teva: títols, URL, <a href> reals, semàntica, dades estructurades, sitemap, imatges i rendiment— i en accessibilitat, on la resposta és més contundent: cap no et salva de fer-ho malament, i de fet tots quatre faciliten escriure un <div onClick> que funciona amb ratolí i amb res més. Amb les quatre fallades que es repeteixen i que ja saps evitar: elements no semàntics, focus perdut en actualitzar, canvis que no s'anuncien i navegació de SPA silenciosa.

Tens un mètode per avaluar tecnologia nova: llegir la documentació buscant-hi les limitacions declarades, comprovar cadència i política de versions amb sis preguntes concretes, mesurar el teu propi exemple amb les eines de 09-01, i fer el prototip d'un dia amb el cas més difícil —no el més representatiu— dedicant l'última hora a escriure el que no has sabut resoldre, que és la millor predicció del que costarà durant un any. I saps que el prototip es llença.

Coneixes les estratègies de migració que funcionen —per rutes, per components muntant el framework nou en un node de la pàgina existent, i per capes començant per baix— davant de la reescriptura total, que és la decisió que més projectes ha enfonsat. I saps que els web components són la frontera quan cal que alguna cosa funcioni a qualsevol lloc: connectedCallback i disconnectedCallback són el cicle de vida de 10-01, attachShadow és l'aïllament d'estils portat a l'estàndard, i el CustomEvent amb bubbles és el teu mecanisme de 06-04 — tot sense framework i amb la durada de la mateixa plataforma.

I tens el balanç final, sostingut per una dada d'aquest mateix mòdul i no per una opinió: el fitxer domini/regles.js va ser idèntic a les quatre versions. Les mateixes quaranta línies en JavaScript pur, React, Vue i Angular. Tot el que va canviar va ser vista. Això és el que separa el que no caduca —el llenguatge, el DOM, HTTP, les proves, el rendiment, l'accessibilitat, el model declaratiu, saber modelar l'estat i el criteri per decidir— del que sí: la sintaxi concreta, el nom del hook, la llibreria de torn, els llindars exactes.

Comença ara el Mòdul 11, i el projecte final es construeix en JavaScript pur, amb Nómada Tasques tal com l'has deixada: sis tasques i 48 hores al tauler, les seves regles R1–R10, les seves 124 proves i els seus tres recorreguts d'extrem a extrem, el seu service worker, els seus 58,3 kB en tres peticions i el seu LCP d'1,9 segons. Res d'això no canvia. El que ha canviat és qui ho decideix: al Mòdul 1 escrivies JavaScript pur perquè era l'únic que sabies, i ara l'escrius amb React, Vue i Angular sobre la taula, amb les quatre versions de la mateixa pantalla mesurades i amb una taula de ponderació que diu, per a aquest projecte i aquest context, que és l'elecció correcta. Aquesta és tota la diferència entre un principiant i un professional, i no és a l'eina: un principiant fa servir el que coneix; un professional tria, sap per què, i ho pot defensar. Amb aquesta capacitat —i amb una aplicació que funciona, es prova, es mesura i es desplega— comença l'últim que queda: Configuració i Planificació del Projecte.