Teknologisk set er det en evighed siden John Resig i 2006 udgav den første version af jQuery. Selvom jQuery ifølge tallene stadig er den helt store spiller, er der en voksende interesse for alternativerne fx. Angular og React.
jQuery er en glimrende abstraktion over browserens (især i starten) varierende API. Den har formået at gøre tærsklen for hvem der kunne udvikle til webbet lavere og skabe fundament for et stort økosystem.
Den næste generation af frameworks lover guld og grønne skove med endnu højere abstraktioner men er det altid et godt valg?
For hvor hvert enkelt framework prismæssigt er gratis, er prisen for at vælge det ofte høj i form af ceremoni og kompleksitet. Angular fylder i sig selv 144 KB i produktionsudgaven – og selv om vi i dag ikke behøver at tænke så meget over download-størrelsen så er det stadig kode der skal afvikles og som potentielt indeholder fejl og skjuler ens egne fejl.
Ikke mindst er browseren i sig selv ved udvikle sig til et framework. De grundfunktioner der tidligere levede i frameworks har fundet vej ind til at blive til browserens API og mulighederne i ren (vanilla) JavaScript bliver bedre og bedre:
Promises som jeg skrev om tidligere krævede enten et separat bibliotek eller framework-understøttelse men er nu flyttet ind i browseren.
Ajax har tradionelt set været lidt omstændigt at bruge i browser med forskellige eventhandlers og en klasse der hedder noget med XML på trods af at man bruger den til meget andet end XML. Fetch skaber et meget mere lækkert API med promises m.v.
DOM manipulation har naturligvis altid beroet på browser-understøttelse men API’et har udviklet sig og man kan fx. i dag fuldt ud bruge CSS-queries til at udvælge elementer. En funktion der oprindelig var implementeret af fx. jQuery’s Sizzle engine.
Virtual DOM er en af Reacts grundfunktioner og er også ved at finde vej ind i mange andre frameworks. Princippet er at man naivt kan lave alle de DOM manipulationer man vil imod en letvægtsstruktur, der så bliver sammenlignet med den rigtige DOM’s elementer, så man kan lave et minimum af ændringer på det rigtige tidspunkt. Det er dog ikke gratis – det bruger meget ram (begrænset ressource på især mobil) og man kan også undre sig over at det ikke er browserproducenterne der laver denne optimering. I sidste ende skal DOM’en stadig manipuleres og igen er browserens API blevet bedre med fx. RequestAnimationFrame og desuden har vi fået profilers indbygget i browseren der kan hjælpe med at finde potentielle kilder til performance-problemer.
Der er andre måder at få dynamisk HTML ud i browseren, fx. <template>-tagget der blev standardiseret for et par år siden eller alternativt med fx. TypeScript og template strings hvor man får man en god editor oplevelse med type-checks, intellisense m.v.
Animationer der tidligere har krævet frameworkfunktioner kan i dag med fordel gøres med CSS for at få hardwareacceleration. Desuden er der et Web animations API på vej hvis man ønsker mere kontrol.
Dialoger, altså popup-bokse med information og valg. Endnu et lille eksempel på et sted hvor browseren er ved at tage over i form af <dialog>-tagget, der umiddelbart ikke gør meget man ikke kan med et <div>-tag, men som gør accessability langt bedre, da en skærmlæser kan genkende og fortolke elementet.
Komponenter er også godt på vej ud i browserne i form af Web Components der samlet set gør det muligt at lave sine egne tags og med shadow DOM kan man sikre at styling af disse tags ikke forbliver inden for den enkelte komponent.
Features der ikke er implementeret af alle browsere kan i de fleste tilfælde polyfilles enten via pakker fra NPM eller fx polyfill.io. Så er vi naturligvis igen tilbage til en verden med mere script og flere bugs men som oftest med et standardiseret API der ikke flytter sig meget og polyfillen kan fjernes når browsersupporten er acceptabel.
Javascript sproget kan også være en udfordring når det kommer til organisation af kode. Mange gode features er på vej såsom namespaces, klasser, template strings osv. men findes ikke i den version af JavaScript som kører i browseren i dag. Her kommer der et prekompileringsstep ind – enten i form af Babel eller TypeScript der muliggør at man skriver fremtidens JavaScript i dag. Dette er igen en forøgelse af kompleksiteten men ikke meget på kørselstidspunktet og map-filer hjælper med til at vi stadig kan finde problemer i den oprindelige kildekode.
Frameworks handler i dag mere om arkitektur end om funktionalitet. De kommer hver især med en opskrift på hvordan vi skal administrere kompleksitet. Stod jeg med et stort team i dag ville jeg nok vælge en af de store frameworks da man i samme åndedrag tilvælger en masse holdninger til hvordan udviklingen skal foregå. Noget der ellers kunne tage lang tid med et stort team.
Men vil man have et klippestabilt API og plads til sine egne meninger så skal man vælge vanilla JavaScript. Man skal være forberedt på at skabe sin egen strategi for komponentopdelt arkitektur men det er jo fuldt ud tilladt at låne principper fra de store frameworks.
Derfor skal jeg også ind at høre om Angular på dette års GOTO konference – om ikke andet så for at forbedre min egen vanilla stack.