Hva Astro er, den tekniske tilnærmingen og hvordan det fungerer

Inntil nylig var det vanlig for meg – som for nesten alle andre – å bruke WordPress når jeg laget et bedriftsnettsted. Av åpenbare grunner: det er enkelt, nesten alt du trenger er allerede utviklet, og etter mange år er arbeidsflyten min svært rask.

Men i det siste prosjektet jeg utviklet, nettstedet til Rondabus, brukte jeg Astro. 

Hvorfor?

Det ble anbefalt i et nyhetsbrev om KI som jeg følger, fordi det ifølge dem fungerer svært godt sammen med agenter.

Og det gjør det virkelig.

Jeg behandlet først og fremst prosjektet som en test av dagens tilstand innen webutvikling. For å se hvor mye som fortsatt avhenger av et menneske, og hvor mye som allerede kan gjøres med KI. Derfor brukte jeg rammeverket som ble anbefalt.

Jeg leste selvfølgelig dokumentasjonen for å forstå om det passet til det jeg ville gjøre. Det er denne dokumentasjonen som ligger bak artikkelen, der jeg forteller det du trenger å vite for å våge å prøve. Og litt til.

Men før vi går løs på saken, et par småting:

Det første er at jeg ble veldig begeistret for HTML first-tilnærmingen. Det er akkurat det jeg har snakket om i årevis.

Det andre er at i dag, når du skal utvikle et nettsted, står ChatGPT eller Claude for alt bortsett fra vurderingsevnen..

Nå begynner vi.

Hva Astro egentlig er

Astro er et rammeverk for å bygge nettsteder, altså et sett med verktøy og retningslinjer som hjelper deg med å generere koden til nettstedet.

Verken mer eller mindre.

Det finnes mange rammeverk, hvert med sine særtrekk. Her skal jeg forklare Astros.

Astro lar deg arbeide med gjenbrukbare deler, delte data og maler. Deretter kombinerer det alt for å produsere nettstedet.

Med andre ord: tenk på hva du trenger for å lage nettstedet til en bedrift: topptekst, meny, tjenestesider, bilder, tekst, skjema og bunntekst. Du kunne skrevet hver side for hånd i HTML, men da ville du gjentatt mye arbeid.

Hvis du endrer telefonnummeret, legger til et menyelement eller en lenke i footeren, måtte du ha oppdatert dette i alle filene på nettstedet. Med Astro slipper du det, fordi elementer gjenbrukes.

Og du kommer til å si: som i WordPress. Ja, det stemmer, men her ligger det ingen database bak.

Du kunne også svart at dette er som i et hvilket som helst serverspråk som PHP. Da ville jeg svart at du ikke trenger å ha noe språk installert på serveren, bare filene lagret der.

Som man gjorde opprinnelig: én HTML-fil per URL med tilhørende CSS og JS.

Du kan faktisk bruke HTML, CSS og JavaScript eller TypeScript, men også legge inn komponenter fra React, Vue eller Svelte hvis du trenger dem, noe jeg ikke gjør.

Og hvordan får man til gjenbrukbare elementer og mange HTML-filer?

Den grunnleggende forskjellen: generer nettstedet før brukeren kommer

For å forstå Astro er det nyttig å skille mellom to tidspunkter for et nettsted:

1. Når det utvikles.
2. Når noen besøker det.

På et tradisjonelt dynamisk nettsted forbereder serveren siden når den mottar en forespørsel. Den kjører kode, henter nødvendige data, plasserer dem i en mal og sender resultatet tilbake til nettleseren.

WordPress fungerer for eksempel slik: PHP kjører applikasjonen, spør databasen og bruker temaet og plugins for å generere siden. Ja, cachen kan lagre et svar og bruke det på nytt, så hele prosessen trenger ikke gjentas ved hvert besøk. Det viktige er å forstå at det finnes en applikasjon som kan produsere svaret mens nettstedet kjører.

Med Astro derimot kan du gjøre dette arbeidet før publisering. Du forbereder sidene, genererer filene og legger resultatet på hostingen. Det kalles en build..

Når noen så åpner kontaktsiden, leverer serveren HTML som allerede er ferdig. Den trenger ikke å bygge toppteksten på nytt, hente telefonnummeret og sette sammen bunnteksten for den besøkende.

Denne arbeidsmåten kalles SSG, eller statisk nettstedsgenerering. Og den har flere fordeler, blant annet at slike nettsteder bokstavelig talt flyr..

Det finnes flere, som jeg forklarer i artikkelen.

Det jeg har fortalt så langt er nok til å gi deg en idé om hva vi snakker om hvis du ikke er teknisk. Hvis du er det, går vi fra nå av dypere inn i hvordan rammeverket fungerer.

Sterk kaffe for kaffeelskere. Du er advart.

La oss snakke om builds

Det første du må forstå er at en build ikke er noe annet enn resultatet av en automatisert prosess som tar alle filene du har skrevet (kode, bilder, stiler) og gjør dem om til en pakke som er klar til å kjøres av serveren eller nettleseren..

Og det er alt.

Du har altså en serie kodefiler som gjør ulike ting. Når du kjører kommandoen for å kompilere builden, identifiserer Astro sidene, henter innholdet, kjører malene og klargjør ressursene, før det til slutt gir deg et komplett statisk nettsted med HTML, CSS og JS (hvis det trengs)..

Du kan for eksempel ha én felles mal og åtte tjenesteposter. Builden kombinerer malen med dataene i hver post og produserer de tilsvarende sidene.

I Astro gjøres dette med kommandoen npm run build , som vanligvis kjører astro build. . Nettstedet som er klart til å lastes opp ligger i mappen dist og er klart til å lastes opp til serveren domenet ditt peker til.

Hvordan en side bygges i Astro

Hvis du ikke er vant til dette, virker ordforrådet mer komplisert enn det er. La oss se på det med et lite bedriftsnettsted.

Hvordan en .astro-fil ser ut

En .astro-fil kan kombinere en del kode med en HTML-lignende mal:

—

const titulo = 'Transporte para tu empresa';

—

<h1>{titulo}</h1>

<p>Organizamos los desplazamientos de tu equipo.</p>

Det som står mellom de to gruppene med bindestreker forbereder dataene. Under ligger malen som bruker dem. Krøllparentesene viser hvor en verdi skal settes inn.

Denne koden kjøres når nettstedet bygges, og nettleseren mottar en vanlig overskrift med tekst og et vanlig avsnitt med innholdet i variabelen titulo.

Komponenter

Elementene som gjenbrukes.. 

For eksempel kan toppteksten være en komponent. Bunnteksten en annen. En mal for hero banner -modulen på tjenestesidene en tredje. Du lagrer dem separat og bruker dem på sidene som trenger dem.

For eksempel kan en side importere Header.astro og Footer.astro og plassere <Header /> i starten og <Footer /> på slutten. Astro gjør disse delene om til tilsvarende HTML-markup.

Props

Disse propsene er dataene du sender til en komponent slik at den kan gjenbrukes med forskjellig innhold..

Hvis du har laget en komponent for hero banner-modulen på tjenestesider, kan du sende inn en tittel, beskrivelse og et bilde. Strukturen beholder designet mens verdiene endres. Dermed kan hero-modulen for tjeneste 1 være én ting og den for tjeneste 2 en annen, med forskjellig innhold, men samme design.

I Astro kan komponenten lese disse verdiene via Astro.props. 

Layouts og slots

En layout er en struktur som deles av flere sider. La oss si at den er som en komponent på et høyere nivå: : en komponent er vanligvis en liten del av siden, mens layouten omfatter praktisk talt hele siden..

Den kan inneholde HTML-dokumentet, metadata, topptekst og bunntekst.

En slot er plassen der hver sides eget innhold settes inn. 

Hvis du kommer fra WordPress, vil dette minne om maler som deler topptekst og bunntekst, mens hovedinnholdet varierer mellom URL-er. Det fungerer ikke helt likt, men har en lignende funksjon: å unngå å bygge det felles på nytt hver gang.

Hvordan Astro organiserer URL-er

Astro bruker et filbasert routingsystem. I et enkelt prosjekt bestemmer plasseringen til en side inne i src/pages adressen dens:

Fil	Rute
src/pages/index.astro	/
src/pages/contacto.astro	/contacto
src/pages/servicios/bodas.astro	/servicios/bodas

Avsluttende skråstrek avhenger av konfigurasjon og hosting, men grunnforholdet er dette.

Du trenger ikke å lage en egen fil manuelt for hver artikkel eller tjeneste. Det gjør at du kan generere mange sider fra én mal og et datasett, uten å kopiere den samme koden om og om igjen.

Hvor innholdet lagres hvis Astro ikke har en database

At Astro ikke krever en database betyr at tekst og data må lagres i en eller annen type kilde; du kan velge hvilken.

Filer, Markdown, JSON og YAML

På et lite nettsted kan noe av teksten ligge direkte i sidene. Delte data, som telefonnummeret, bør skilles ut så du slipper å endre dem på tjue steder.

En artikkel kan lagres i Markdown, et tekstformat med enkel markering for overskrifter, lister og lenker. JSON og YAML brukes til å organisere data: tjenesteposter, kjøretøyinformasjon eller tekster per språk, for eksempel.

Det er ulike formater for ulike behov. Du trenger ikke bruke alle eller gjøre hver setning på nettstedet om til en komplisert struktur.

Content Collections

Disse Content Collections, eller innholdssamlinger, hjelper med å organisere sett med dataposter og definere strukturen deres..

Se for deg en samling tjenester der hver post må ha tittel, beskrivelse og bilde. Du kan definere disse reglene og validere dataene, slik at det blir lettere å oppdage en ufullstendig post eller en verdi av feil type.

Hvis du kjenner innholdstyper og egendefinerte felt i WordPress, vil ideen om å organisere poster føles kjent.

Avansert innhold: API-er, CMS-er og eksterne databaser

Selv om vi genererer statiske nettsteder, kan innholdet også komme fra et CMS, et API eller en database. Et API er en måte to systemer kan utveksle informasjon på: Astro ber om data, og det andre systemet leverer dem.

Du kan til og med bruke WordPress som kilde for artikler og bygge den offentlige delen med Astro. Vi kommer tilbake til denne kombinasjonen i Astro vs WordPress..

Det avgjørende spørsmålet er når du henter denne informasjonen. Hvis den legges inn under builden, endrer ikke en endring i kilden publisert HTML før du genererer det på nytt. Hvis den hentes under en forespørsel eller fra nettleseren, oppfører det seg annerledes og mer som tradisjonelle dynamiske sider.

Hva Astro Islands er

En side kan ha mye innhold som du bare trenger å lese, og en liten del du ønsker å samhandle med. For eksempel en priskalkulator på en tjenesteside. Eller et skjema..

Arkitekturen med øyer gjør at den komponenten kan ha sin egen oppførsel uten å gjøre hele siden om til en applikasjon som kjører i nettleseren.

Hva det betyr å hydrere en komponent

Hydrering betyr å legge koden til en interaktiv komponent til HTML som allerede er generert, slik at den kan reagere på brukerhandlinger.

Kalkulatoren eller skjemaet kan vises når siden lastes og deretter aktivere logikken sin.. 

Her snakker vi om klientøyer. Astro har også serverøyer for å håndtere dynamiske deler separat, selv om vi ikke trenger å gå inn på dem for å forstå denne første forklaringen.

Når nettleseren trenger JavaScript

Ikke all interaksjon krever en øy. En lenke fungerer med HTML. En enkel nedtrekksmeny kan løses med HTML og CSS.

En kalkulator som oppdaterer resultater mens du endrer alternativer, trenger derimot vanligvis JavaScript. Og skjemaet trenger en integrasjon eller et serverspråk for å sende dataene.

Og her liker jeg Astros tilnærming veldig godt: avgjørelsen tas ut fra funksjonen du vil tilby, ikke den utslitte ideen om at et moderne nettsted må laste en hel applikasjon..

Astro prøver å sende null JavaScript som standard

Pass på at vi ikke blander begrepene: vi snakker om nettstedet brukeren ser.. 

For Astro bruker JavaScript til utvikling og kompilering, men .astro -komponenter trenger ikke sende forberedelseskoden sin til nettleseren. 

Script du legger til, øyer du hydrerer og eksterne verktøy kan likevel legge til JavaScript. En chat, en analyseplattform (GA4) eller en innebygd video trenger det.

Derfor: «null JavaScript som standard» er utgangspunktet, ikke et krav.

Og som jeg forklarer lenger ned, passer dette for meg svært godt til utvikling av bedriftsnettsteder, for eksempel.

Astro kan være statisk, dynamisk eller en kombinasjon av begge

Greit, hittil har jeg fokusert på én tilnærming, men det finnes to muligheter.

SSG

Det vi har sett hittil: siden genereres før besøkene, under builden. 

Det er perfekt når innholdet kan forbli likt for alle fram til neste publisering. Altså for sider som ikke endrer seg mye.

SSR

Siden genereres på serveren ved behov. Den kan bruke informasjon som ikke finnes under builden, som data knyttet til en økt. 

Da holder det ikke med hvilken som helst server: du trenger et kompatibelt kjøremiljø og riktig adapter.

Hybrid rendering

Du kan kombinere forhåndsrenderte sider og sider som genereres ved behov. For eksempel kan du holde de offentlige sidene klare på forhånd og håndtere et privat område på serveren.

Hvilken rolle Node.js og Vite har

Node.js gjør det mulig å kjøre JavaScript utenfor nettleseren. I et vanlig Astro-prosjekt brukes det i utviklingen og når builden bygges, der npm hjelper med å administrere pakker og kommandoer. For et statisk nettsted trenger Node.js ikke kjøre på produksjonsserveren som hoster builden.

Vite er en motor som brukes av mange moderne rammeverk. Den er en del av maskineriet Astro bruker for å jobbe med filene og tilby utviklingsmiljøet. 

Det holder for å gi deg et bilde.

Hvordan et Astro-prosjekt er organisert

Når du åpner et prosjekt, ser du mapper som ikke er sider, og filer som ikke publiseres. Dette lille kartet hjelper deg å skille dem.

src

Inneholder kildekoden: sider, komponenter, layouts og andre arbeidsfiler. Det er her mye av nettstedet bygges.

public

Inneholder ressurser som leveres uten den vanlige behandlingen av importerte filer: for eksempel en robots.txt eller bestemte bilder. Alt du legger her blir offentlig, så dette er ikke stedet for påloggingsopplysninger.

package.json

Beskriver prosjektet, avhengighetene og scriptene. Her defineres det hva kommandoer som npm run build kjører. Låsefilen for avhengigheter bidrar til å beholde bestemte versjoner slik at installasjonen kan gjentas.

node_modules

Dette er mappen der pakkene prosjektet trenger blir installert. Den bygges vanligvis opp igjen fra avhengighetsfilene og lagres ikke i sin helhet i Git.

dist

Inneholder produksjonsutdata etter builden. For et statisk nettsted finner du her filene som er klare til publisering.

Hva nettleseren og Google faktisk laster

Jeg gjentar det én gang til for dem på bakerste rad: nettleseren mottar ikke prosjektet ditt slik du ser det i editoren. Den mottar HTML-en og ressursene som trengs for å vise og bruke siden.

En søkemotor som ber om denne URL-en, mottar HTML-en, enten du forberedte den under builden eller genererte den på serveren. Det garanterer ikke at den blir indeksert eller rangerer godt: innhold, lenker og innstillinger for crawling og indeksering er fortsatt viktige, men etter min erfaring kan det som mottas optimaliseres veldig, veldig godt.

Poenget jeg vil at du skal sitte igjen med er dette: alle disse malene, samlingene og komponentene brukes til å produsere et nettsted som fortsatt benytter de samme velkjente teknologiene. Astro styrer opprettelsen av nettstedet; den resulterende HTML-en mottas av en nettleser.

Konklusjon: hvilke typer nettsteder Astro gir mening for

Denne arbeidsmåten passer godt for nettsteder der innholdet ikke endres altfor mye:

• Bedriftsnettsteder.
• Porteføljer
• Landingssider.

Jeg ville ikke anbefalt det for magasiner, blogger og nettsteder der det opprettes mye innhold eller flere innholdsskapere jobber. Til det foretrekker jeg fortsatt WordPress fremfor Astro..

Hvis du liker tilnærmingen og vil vite mer, kan du fortsette med å lese om fordelene og ulempene ved Astro..

Og hvis du heller vil se det brukt i et komplett prosjekt, har jeg laget prosessen for å lage et nettsted for en lokal bedrift med KI, med mitt siste prosjekt som eksempel.

Jeg garanterer at når du først har prøvd det, vil du ikke tilbake.