mikkel lauritsen bloghoved den gode kode

Brug-og-smid-væk-kode?

For halvandet års tid siden lavede vi på mit arbejde en forenklet brugergrænseflade til vores applikationer, primært rettet mod mobile devices. Den er blevet særdeles vel modtaget af brugerne, og vi skal til at lave en pendant, bare med fokus på anden funktionalitet.

Mere teknisk er det en JavaScript-baseret applikation, lavet med React, og som kommunikerer med server-moderskibet ved at kalde nogen REST-agtige services lavet med Jersey. Vi overvejede at lave platformspecifikke apps, men vi har ikke fortrudt den webbaserede løsning - mængden af arbejde i at få tingene til at køre på alle relevante platforme (Android, iOS, Windows Phone/Mobile/nameoftheday og div. desktop-operativsystemer) har været minimal, og brugeroplevelsen er glimrende.

En enkelt dråbe malurt er der dog at spore i bægeret, for det er godt nok imponerende, så hurtigt JavaScript-komponenter, biblioteker og frameworks opstår og går af mode. Hvad der er hot i dag er not i næste måned, og det er i bogstaveligste forstand.

Da jeg valgte React til at bygge brugergrænsefladen var det primært af to årsager. Den ene var, at React i modsætning til fx AngularJS for mig at se var mere umiddelbart tilgængelig og bare gav mening - det tog ikke ret lang tid at forstå de grundlæggende koncepter. Den anden nok så vigtige årsag var, at det er Facebook, som står bag React og selv bruger det. Det borger for, at det kan bruges, og der er mindst én resourcestærk organisation som har en interesse i at sikre, at koden videreudvikles.

Det bliver den, for i løbet af de halvandet år er selve React er kommet i nye versioner, som ikke er API-kompatible med de tidligere, og derudover er der er også en masse "udenoms", som er lavet om eller blevet udskiftningsmodent. Selv byggeværktøjerne; i dag er det fx tilsyneladende webpack som er det nye sort. Nettoresultatet er, at vi er nødt til at skrive store dele af vores kode om, hvilket kan være mere eller mindre ligetil - i nogen tilfælde er komponenters dokumentation... æh, mindre fantastisk, så der skal graves i kodeeksempler, blogs og andre steder for at finde ud af, hvad der er sket af ændringer.

Og det er muligt, at jeg lyder som et utaknemmeligt skarn, fordi det selvfølgelig også er godt, at der hele tiden opstår så mange højkvalitetskomponenter til fri afbenyttelse. Det er bare tæt på at være et fuldtidsjob at opretholde et overblik, selv for en lille organisation som den, jeg repræsenterer, så lidt mere fælles retning på tingene ville være en god ting.

Traditionen i Java-verdenen er at have store specifikationer (Java EE og dens delspecifikationer, fx), som der er bred opbakning til, og som videreudvikles på bagudkompatibel vis over lang tid. Det kan sagtens lade sig gøre at finde noget at kritisere de ret tunge kommitedrevne processer for (det går for langsomt, for lidt innovation, you name it), men det har haft den meget positive virkning, at der er ret lidt "churn". Ens gamle kode virker i store træk stadig, selv om man opgraderer.

Om noget tilsvarende nogensinde kommer til at gøre sig gældende på JavaScript-fronten er et godt spørgsmål.

Kommentarer (7)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Mikkel Lauritsen

Var det så det forkerte teknologi-valg som I traf for halvandet år siden?

Godt spørgsmål - nej, det synes jeg ikke. Eller rettere: det tror jeg ikke. En af udfordringerne er netop, at vi ikke har mulighed for at undersøge alternativerne tilstrækkeligt i dybden til at jeg kan udtale mig med 100% sikkerhed om hvorvidt de er bedre.

Like it or not; hvis man vil lave en moderne webbaseret brugergrænseflade er der ikke nogen vej udenom JavaScript på klienten. Og med det aksiom har React og dertil hørende komponenter (react-router fx) vist sig at være et udmærket valg. Det er en stabil runtimeplatform og vores produktivitet er høj.

  • 0
  • 0
Mikkel Lauritsen

Er der behov for at opdatere til en nyere og inkompatibel udgave hvis den gamle stadigvæk fungerer? Hvis inkompatible opgraderinger er hyppige, så kunne der være fidus i at springe nogen af dem over.

Nej, det er der kun i begrænset omfang indenfor den eksisterende applikation. Der er altid ting som sikkerhedshuller at tage hensyn til, men det er begrænset, hvor stor skade de kan gøre i en applikation, som kører på klienten, og hvor vi har fuld kontrol over, hvad serveren slipper ud.

Der, hvor skoen trykker, er den nye applikation, der skal laves. Det vil ikke rigtig give mening at basere den på en gammel udgave af React og venner, fordi de nye bare er bedre, men det betyder, at de dele, der trods alt kan genbruges, skal modificeres kraftigt.

  • 0
  • 0
Mikkel Lauritsen

Og med det aksiom har React og dertil hørende komponenter (react-router fx) vist sig at være et udmærket valg.

FWIW, hvis vi nu havde kastet os over AngularJS havde min holdning nok været anderledes, på linje med hvad flere andre synes. Der har man valgt at lave en total omskrivning fra version 1 til version 2, så det for alvor er øvelse forfra med de applikationer, der bygger på frameworket.

Det er lidt af en katastrofe, hvis man ender med at kaste meget arbejde efter en platform, som viser sig at være så kortlivet.

  • 0
  • 0
Allan Ebdrup

Det er lidt af en katastrofe, hvis man ender med at kaste meget arbejde efter en platform, som viser sig at være så kortlivet.

I det mindste kan din applikation kører videre, fordi det er åbne standarder der ligger som grundsten. Det ser nok lidt mere sort ud for dem der i sin tid valgte Flash/Java-applet/ActiveX/Silverlight.

Men ja det går hurtigt for front-end frameworks. Spørgsmålet er om det bare er noget man må vænne sig til - for nu har det været sådan i rigtig mange år.

Jeg rettede selv en gammel React app til for nylig - den var ikke så slem at få opdateret til nyeste React. React gav endda pæne hints til hvordan jeg kunne rette den til.

  • 0
  • 0
Peter Christiansen

Er der behov for at opdatere til en nyere og inkompatibel udgave hvis den gamle stadigvæk fungerer? Hvis inkompatible opgraderinger er hyppige, så kunne der være fidus i at springe nogen af dem over.

Det var umiddelbart også min tanke, specielt set at det er javascript og kører i browseren. Sikkerhedsmæssigt set er det lige gyldigt om et javascript api er i nyeste version eller ej, bare man husker altid at hoste det selv.

Selvfølgelig hvis man savner den nye funktionalitet i opgraderingerne, er der ikke noget valg, med mindre man kan programmere det selv.

  • 0
  • 0
Log ind eller Opret konto for at kommentere