Som konsulent i utviklerbransjen blir man gjerne kastet ut på dypt vann av sine sjefer. Selv fikk jeg i oppdrag å holde et foredrag og fylle en podcast-episode med temaet “Moderne web-rammeverk”.
Etter å ha tilbrakt to år med å vedlikeholde CRA-applikasjoner for en kunde, følte jeg imidlertid at jeg ikke hadde så mye å komme med. Selv om jeg har oppgradert et par av disse til Vite, virket det fortsatt ikke særlig "moderne".
I ren desperasjon bestemte jeg meg for å prøve et rammeverk jeg aldri hadde hørt om før: Astro.js.
Ikke bare ble jeg begeistret, men Astro fikk meg også til å reflektere over min reise som web-utvikler, hva rammeverk egentlig er, og min rolle i det hele.
Dette er min historie.
Webutvikling i gamledager
Det verktøyet absolutt alle som leverer web-applikasjoner bør ha solid kunnskap om, er nettleseren. En nettleser utgjør et komplett rammeverk for utvikling av applikasjoner, hvis du har en enkel teksteditor som notepad i tillegg.
Min egen reise inn i utviklerverden startet som tenåring da jeg surfet på nettet med Internet Explorer (kan det ha vært versjon 6?). En dag dukket det opp en Javascript-feil på en nettside, noe som fikk et program kalt "Script Debugger" til å poppe opp.
Dette programmet føltes som ren magi, med spennende kodelinjer som fanget min interesse. Til min overraskelse inneholdt hjelpesystemet grunnleggende informasjon om hvordan man kunne programmere både i JavaScript og VBScript.
Artige.no tok så av at den ble kasta ut av Domeneshop
Jeg kunne litt HTML fra før, så det var bare å sette i gang. Sammen med den tykkeste boken jeg noensinne har eid (the Javascript Bible av Danny Goodman, større enn Atlas Shrugged), som beskrev hele DOM-APIet, kunne jeg lage enkle programmer som “Stein, Saks, Papir med Hal 9000” (datamaskinen vant alltid).
Oppdaget jeg kul design eller funksjonalitet på andre nettsider, kunne jeg enkelt bruke browseren til å grave i denne koden, og la meg inspirere av hjertens lyst.
«Nå har det gått 23 år, og hva har egentlig skjedd?»
Noe har blitt bedre
Hva er det jeg ønsker å formidle med dette? Jo, allerede i 2001 kunne en relativt uerfaren tenåring sette seg ned og begynne å programmere nettsider med bare Notepad og programmene som fulgte med en helt vanlig Windows-installasjon (Internet Explorer og Script Debugger). Utvikleropplevelsen, eller DX som vi kaller det i dag, var fenomenal.
Nå har det gått 23 år, og hva har egentlig skjedd?
På den positive siden, så har browseren utviklet seg enormt. Alle de store nettleserne (Chrome, Firefox og Safari) har innebygde utviklerverktøy som er imponerende. Du kan inspisere kode, overvåke nettverkstrafikk, stoppe og trinnvis gå gjennom kodekjøringen, redigere DOM-treet, og mye mer. Mulighetene er mange, og det dukker stadig opp nye funksjoner.
I tillegg har browseren veldig mange APIer og funksjonalitet innebygd, som kan brukes ut av boksen. Dialoger, datovelgere, CSS-animasjoner, notifikasjoner er alt bygd inn i browseren.
Nyttige APIer som tar vare på informasjon hvis man lukker og åpner browseren igjen (localStorage). Som forteller deg om et element kommer til syne eller forsvinner under scrolling. Som varsler deg om DOM-treet har blitt endret på. I tillegg har man morsomme APIer, som MIDI, lydmanipulering, Canvas, med mer.
Legges ned, etter å ha prega Norge siden 1996
Noe har blitt verre
På den andre siden har vi alle de moderne web-rammeverkene, som ser ut til å være i en konstant kamp mot browseren.
Minifisering av koden gjør det vanskelig, om ikke umulig, å bruke browserens innebygde utviklerverktøy effektivt. Tidligere kunne hvem som helst inspisere en nettside for å lære hvordan utviklerne hadde implementert sine nye, smarte funksjoner.
Men med nye språk som JSX og TypeScript, blir man tvunget til å bruke ulike verktøy for å oversette koden til noe browseren forstår – nemlig HTML og JavaScript. Disse rammeverkene har gjort terskelen for å skrive nettsider og applikasjoner høyere, og den enkle tilgangen vi en gang hadde til å forstå og lære fra andres arbeid har blitt mer utfordrende.
Skaper avstand til browser
Jeg er ikke idiot. Jeg forstår godt at disse moderne rammeverkene gjør livet mitt som web-utvikler mye enklere og mer effektivt.
Selv om jeg på hobbybasis liker å skrive HTML og JavaScript direkte til browseren på ulike måter – for eksempel ved å bruke Preact med HTM (Hyperscript Tagged Markup), som ikke krever noe byggesteg og kan leveres direkte til browseren – benytter jeg selvfølgelig TypeScript for typesikkerhet, JSX for å skrive gjenbrukbare komponenter, og byggesystemer for å levere store applikasjoner.
Jeg forstår fullt ut at en stor applikasjon blir vanskelig å vedlikeholde over tid uten disse nyttige verktøyene.
Likevel er det tankevekkende at disse moderne rammeverkene har skapt en avstand mellom web-utvikleren og browseren – det stedet der applikasjonen faktisk lever og blir opplevd av sluttbrukeren.
– Jeg trives ikke lenger på internett
Trenger du rammeverket?
Min klare oppfatning er at før frontend-utviklere begynner å lære seg moderne rammeverk, bør de først sette seg inn i hvilke muligheter browseren og web-plattformen allerede tilbyr, uten å ty til et rammeverk.
Det er ofte unødvendig å gjenoppfinne hjulet når browseren gir oss ferdige løsninger, som kontinuerlig blir vedlikeholdt av noen av verdens største teknologiselskaper som Mozilla, Apple og Alphabet.
Kanskje browserens innebygde funksjoner for skjema-validering er mer enn tilstrekkelig for din applikasjon? Enhver knapp inne i et skjema vil for eksempel automatisk POSTe skjemaet til serveren, så kanskje du ikke engang trenger JavaScript for å gjennomføre den spørreundersøkelsen du planlegger.
Alle teknologiene du finner i browseren er også grundig dokumentert, blant annet gjennom prosjekter som MDN og W3Schools. Selv om du skal bygge applikasjoner med React, Svelte, Vue, eller andre rammeverk, forblir den underliggende teknologien den samme.
Det er nettopp denne grunnleggende forståelsen av browserens muligheter og begrensninger som gir deg et sterkt fundament, uansett hvilket moderne rammeverk du velger å jobbe med.
Angular og React
Spol ti år fremover, og jeg er ikke lenger en kvisete tenåring som fascineres av magien når en debugger dukker opp med feilmeldinger på skjermen. Plutselig vedlikeholder jeg et regnskapssystem med 400 servergenererte sider, hvor den dynamiske funksjonaliteten er implementert i en blanding av jQuery og vanilla JavaScript.
Da jeg overtok vedlikeholdet, ble all JavaScript og CSS levert "as is" til browseren. Gjenbruk av kode ble gjort ved å definere funksjoner i globalt scope (altså på window), som deretter ble brukt vilkårlig i ulike kodefiler. Vi var derfor avhengige av at all kode ble lastet i "riktig rekkefølge" av browseren (og at absolutt alle funksjoner hadde forskjellige navn).
Mye tid gikk med til å modernisere dette – blant annet gjennom modularisering av JavaScript, kompilering av CSS som SASS-filer, og til og med polyfilling av funksjonalitet som eldre browsere kanskje manglet. Alt ble sydd sammen ved hjelp av Gulp.
«Selv om dette var en fornuftig løsning for Facebook, var det ikke nødvendigvis den mest optimale tilnærmingen for alle andre.»
Samtidig dukket det opp spennende verktøy som Angular og React, som lovet å forbedre utvikleropplevelsen for webapplikasjoner. Jeg hørte at moderne webapplikasjoner nå ofte bare sendte en tom <div /> til nettleseren, og at Angular eller React tok seg av resten. Rendering av siden ble dermed klientbasert, altså utført av browseren, i det som kalles en Single Page Application (SPA).
Samtidig visste jeg at React ble utviklet av Facebook, en PHP-applikasjon, som brukte React til å kjøre ulike "widgets" på forskjellige sider, men uten å omfavne SPA-konseptet fullt ut selv.
Behovet for Facebook å flytte rendering til klienten var åpenbart: Som verdens største sosiale plattform med millioner av samtidige brukere ble det kostbart å rendere alle sidene på serversiden. De innoverte også PHP for å gjøre server-side rendering mer effektiv.
Selv om dette var en fornuftig løsning for Facebook, var det ikke nødvendigvis den mest optimale tilnærmingen for alle andre.
– Astro gir deg superkrefter! mener Stian, som svarer på alt vi lurer på
Klient- vs. server-side
Mange utviklere fulgte etter og begynte å bruke klientside-rendering som standard, noe som ledet til fremveksten av verktøy som React.
Men etter hvert oppstod behovet for å kombinere det beste fra begge verdener – klientside-interaktivitet og server-side effektivitet. Dette førte til at vi fikk rammeverk som Next.js, som tok React-koden og rendret den til HTML på serversiden før den ble sendt til klienten.
Dette konseptet, kjent som Server Side Rendering (SSR), er ikke nytt – teknologier som PHP, JSP og ASP har gjort dette i årevis.
Forskjellen nå er at utviklere kan bruke den samme komponentbaserte koden både på server- og klientsiden, uten å måtte lære flere templating-språk. Dette gjør det enklere å håndtere dynamiske applikasjoner og samtidig dra nytte av fordelene fra Single Page Applications (SPA), som å holde applikasjonens tilstand separat fra DOM-treet.
Med moderne SSR kan vi nå levere ferdig rendret HTML raskere til klienten, samtidig som vi beholder fleksibiliteten og ytelsen i applikasjonen.
5 ting utviklere har googla i 20 år
Astros nye tilnærming
Mens utviklingen av verktøy som Next.js har brakt server-side rendering tilbake i rampelyset, har det nylig dukket opp et annet rammeverk som jeg har blitt spesielt begeistret for: Astro.js.
Astro tilbyr en tilnærming der mye, om ikke all, HTML kan genereres allerede når applikasjonen bygges. I stedet for å rendres på serveren ved hver enkelt forespørsel, eller av klienten etter at all koden er lastet inn, blir HTML generert av byggesystemet før applikasjonen i det hele tatt deployes til produksjon. Denne metoden kalles Static Site Generation (SSG), og før Astro har SSG stort sett vært forbeholdt enkle HTML-sider uten særlig dynamisk funksjonalitet.
Astro introduserer et nytt konsept med interaktive "islands" – små applikasjoner eller widgets skrevet i moderne verktøy som React, Vue, Svelte eller Angular. Dette gjør det mulig å bygge et nettsted der mesteparten av HTML-en genereres én gang og leveres direkte til browseren, mens dynamiske komponenter bare aktiveres der det er nødvendig.
Dette er spesielt effektivt for nettsteder eller applikasjoner med mange statiske sider og få interaktive elementer, og det kan til og med være mer effektivt enn tradisjonelle cache-systemer som ofte er komplekse å vedlikeholde og kan føre til kritiske feil.
Derfor byttet han fra Next.js til Astro
Astro støtter alt
Selv om SSG ikke er ideelt for applikasjoner med sterkt skreddersydd innhold for hver bruker, eller for nettaviser som må generere store mengder statisk HTML ved byggtid, er det et utmerket valg for web-applikasjoner med en stor andel statiske sider og noen få dynamiske komponenter.
For eksempel kan det være perfekt for bedriftsnettsteder, blogger, landingssider, hjelpesider og mindre nettbutikker. Og skal du vedlikeholde en større nettavis, støtter Astro også SSR, noe det ser ut som at VG gjør seg nytte av!
Med Astro kan du fritt bruke ditt favoritt-komponentsystem, implementert i React eller Svelte, eller skrive rene statiske sider i Markdown eller MDX. Astro støtter mange ulike rammeverk, noe som gjør det mulig å bruke det som et "overbygg" mens du gradvis migrerer en applikasjon fra ett rammeverk til et annet.
Dette gir utviklere muligheten til å kombinere ulike verktøy i samme prosjekt uten å måtte starte helt fra bunnen av, og du kan også velge å skrive nettsider i helt vanlig HTML om ønskelig.
VG bytter til Astro: «Større fleksibilitet»
Fortsatt HTML, JS, CSS
Vi som utviklere må ikke glemme at nettsider fremdeles først og fremst består av HTML, JS og CSS. Vi gir HTML-dokumenter dynamisk oppførsel ved hjelp av JavaScript, og pynter dem med CSS. Når vi bruker moderne web-rammeverk, er disse bare verktøy som omgjør språkene vi skriver i (JSX, TypeScript, SASS, etc.) til HTML, JS og CSS.
Hvis vi ikke forstår hvordan HTML, JavaScript eller CSS fungerer, forstår vi heller ikke hvordan websidene egentlig fungerer. Uten denne grunnleggende forståelsen, blir det vanskeligere for oss å feilsøke uvanlige feil, vanskeligere å forstå hvordan og hvorfor applikasjonen fungerer som den gjør, og vanskeligere å tilpasse oss det neste nye web-rammeverket som ennå ikke er lansert.
Til syvende og sist handler webutvikling om å forstå de grunnleggende teknologiene som driver nettet. Selv om moderne rammeverk gir oss mange fordeler, er det viktig å huske at HTML, JavaScript og CSS alltid ligger i bunn. Å ha en solid forståelse av disse gir deg en sterkere plattform, uansett hvilket rammeverk du velger å jobbe med.
Utforsk gjerne enkle verktøy som Neocities for å gjenoppdage gleden ved å bygge nettsider fra bunnen av – uten kompleksiteten av moderne byggesystemer.
