BLOG
DIGITAL

Blog: JavaScript Framework

Det er lige før, at der er ligeså mange holdninger til hvilket framework man skal vælge, som der er frameworks at vælge imellem.

[22. september 2016] Et af de hyppigste spørgsmål jeg støder på er: ”Hvilket JavaScript framework skal vi vælge?”

Ofte efterfulgt af: ”Nogle af vores udviklere siger Angular, andre siger React?”.

De seneste år har der dog også været en eksponentiel stigende tilgang af nye frameworks, som alt andet lige gør det en smule mere omstændeligt at finde rundt i. Fælles for dem alle sammen er, at de forsøger at løse en eller flere problemstillinger - nogle af dem overlapper givetvis en smule - og i meget forskellige størrelsesordener.

Jeg har tidligere været fortaler for AngularJS som det rette framework til alt. Så skiftede vinden retning, og så var jeg fortaler for React i stedet, og sådan kunne jeg blive ved. Pointen er, at jeg mere end én gang i min karriere har truffet et valg af framework, uden rigtigt at overveje hvorfor - andet end at jeg synes det var det fedeste, nye, skinnende framework, og at mange andre også syntes det samme.

Inden du hopper med på samme hype train, som jeg har været pendler på et par gange, bør du overveje dit eventuelle valg af framework, så du har et fornuftigt og gennemtænkt grundlag for det, der godt kan hen og blive en stor investering.

 

1.  Ydeevne og stabilitet

a) Episerver, eller andet CMS/CMF, renderer og cacher indhold samt præsentationslag.

b) Klienten indlæser SPAen (Single Page Application, SPA, er en hel (web) applikation serveret på én enkelt server-renderet side) framework, eksekverer og renderer dynamiske templates og beriger med indhold. Måske.

Det er sat lidt på spidsen for indlæggets skyld, men i bund og grund er det et spørgsmål om at overlade genereringen af hele dit site til klienten, eller at lade serveren stå med ansvaret. Og med klienten menes der naturligvis browseren. Problemet her kan være, og i langt de fleste fejls tilfælde ER det, et spørgsmål om et meget spredt browsermarked.

Hvis serveren smider en fejl, så logges den, og så er det spørgsmål om, for udviklerne, at rette fejlen i ét miljø. Hvis klienten smider en fejl, så ved du, som site owner, det nødvendigvis ikke. Der findes selvfølgelig en række services som kan logge client side errors, med varierende succes, men du skal stadig kunne replikere det eksakte browsermiljø og eventuelt også de pågældende netværksforhold for tidspunktet fejlen optrådte, for at kunne genskabe den. Hvis du ikke kan genskabe fejlen, er det i de fleste tilfælde så godt som umuligt at rette den. Ofte er det heller ikke nok blot at vide hvor fejlen skete, da der kan være forudgående brugerinteraktioner, som er med til at trigge den. Dvs. kravet for en klar user story i processen med at lokalisere en fejl er et must, men det fortæller en ’client side error logger’ dig typisk ikke. Så med mindre du kan genskabe fejlen på egen hånd, vil udviklerne ende i et debug hell.

Med andre ord, så er det nemmere at rette fejl via serverside validation end det er via Runtime validation.

Og som kunde i et forretningskritisk webprojekt undgår du at udviklere, måske pga. tidspres eller blindt on-boarding på The Hype Train, laver forretningslogik i klienten, som er svær at rette, og som er browserafhængig.

Det er værd at nævne, at ovennævnte klientfejl ikke er isoleret til JavaScript frameworks, men JavaScript generelt.

Bare fordi man kan, er det ikke ens betydende med at man skal.

2. SEO

Det er ikke fordi det er umuligt at lave indeksérbare, JavaScript baserede SPA løsninger, det er bare det med det, at det kræver know-how, tid og fokus af udviklerne, for at implementere og vedligeholde det.

Med en server renderet mark-up og content-struktur, er det standard.

Dertil kommer, at Episerver (eller et andet CMS), som oftes i GUI’en understøtter SEO (Meta Keywords, Meta description, H1, H2, osv) i den template som redaktøren skriver i. Hvis man renderer alt det indhold, der produceres clientside, så skal der i udviklingsprocessen for det første bruges tid på at lave databinding til de felter, der er i GUI for redaktører til SEO og for det andet udvide sit testarbejde til også at tjekke at samtlige databindings er lavet korrekt.

3. Formål og nødvendighed

Dette er min sidste pointe, og den bliver lidt længere - brace yourselves.

For at kunne træffe en kvalificeret beslutning omkring hvilket framework, hvis noget overhovedet, man skal implementere på sin løsning, bliver man nødt til at finde ud af hvad formålet skal være.

Når man kender formålet, er det lettere at finde det mest passende framework til samme. I samme svar ligger også et relativt svar på nødvendigheden.

Langt de fleste sites er baseret på et CMS/CMF, som ofte er et lag oven på noget mere forretningsorienteret softwarearkitektur. Disse systemer kan, for de fleste almindelige* sites vedkommende, det der skal til.

* Med ”almindelige” sites mener jeg det gængse informationsorienterede profilsite, med en overvejende mængde statiske informationssider à la ”Om os”, ”Vi tilbyder”, ”Kontakt os”, etc. Altså sider med lille ændringsfrekvens.
I den anden grøft er der sites baseret på væsentligt mere dynamisk indhold, med en høj ændringsfrekvens, hvor server side rendering og caching i mange tilfælde ville være server-suicide. Facebook og Twitter f.eks., hvor man som bruger har skræddersyet indhold ud fra præferencer, adfærdshistorik, etc.

 

Det vil altså sige, at du har et produkt, baseret på én slags framework, og du nu skal til at overveje at putte endnu et framework OVEN på det eksisterende framework.
Sagt med andre ord: du har betalt for et komplet CMS, og betaler givetvis en årlig licens oveni, som gør det muligt for dine web redaktører at oprette artikler, dynamiske landingssider, Digital Marketing, kampagner, osv., med værktøjer, der gør det muligt at tænke ud af boksen.
Men fordi du har valgt at hele front-enden skal præsenteres igennem et fancy framework med smarte transitions, for at få den der populære web app feeling, vil der være grænser for hvad dine redaktører faktisk kan publicere uden indblanding fra en frontend-udvikler, da der så ville skulle laves et tilsvarende præsentationslag i frameworket, der vil kunne håndtere eksempelvis den nye specielle artikelform, som din redaktør har strikket sammen, og der ville skulle oprettes databindings ned til din EPISERVER, for at få det til at spille efter hensigten.

I langt de flestes tilfælde vil det på hovedsitet være tilstrækkeligt at køre med server side rendering til alt det statiske indhold og selve strukturen af sitet, og så bruge micro-libraries eller mindre frameworks til at skabe en værdiforøgelse i form af dynamisk databerigelse.

I samme ombæring, men ikke betinget af ovenstående, kan man med fordel bruge de større SPA frameworks, såsom AngularJS, til mere eller mindre isolerede micro-sites, som f.eks. en planlagt kampagneside, der kunne have til formål at præsentere et udvalgt produkt eller gennemføre en række trin med dynamisk brugerinput, ofte også brugt i forbindelse med spørgeskemaer, e-learning, etc.

Det altså min pointe, at JavaScript frameworks og libraries såsom AngularJS, KnockoutJS, ReactJS osv. er gode værktøjer til at benytte på flows og andet, hvor der skal vises dynamisk indhold på sider eller hvor der er et kritisk flow/wizard for brugere, men statiske sider og sider, hvor man som redaktør ønsker at kunne opdatere tekster, lave personaliseret indhold eller arbejde med at styrke konverteringen gennem brug af de features som moderne CMS’er tilbyder, der skal man være varsom – og ikke bare hoppe på the Hype Train!

 

JS framework and libraries

Afslutningsvis vil jeg sige, at det er umuligt at dække over alle user cases for den stadig stigende mængde af JavaScript frameworks i et enkelt blogindlæg, men jeg håber at min pointe med indlægget giver mening; Analysér, argumentér og udvis rettidig omhu, inden I træffer en beslutning om jeres frontend.

Comic - http://www.commitstrip.com/en/2015/09/16/how-to-choose-the-right-javascript-framework/ - http://www.commitstrip.com/

 

Kasper Warmdal Filstrup
Kasper Warmdal Filstrup
Senior Consultant
+45 5218 9278
todo todo