Vad Astro är, dess tekniska angreppssätt och hur det fungerar

Fram till nyligen var det vanliga för mig — liksom för nästan alla andra — att använda WordPress när jag byggde en företagswebbplats. Av uppenbara skäl: det är enkelt, nästan allt du behöver finns redan utvecklat och efter många år är mitt arbetsflöde väldigt snabbt.

Men i mitt senaste projekt, webbplatsen för Rondabus, använde jag Astro. 

Varför?

Det rekommenderades i ett AI-nyhetsbrev som jag följer, eftersom det enligt dem fungerar väldigt bra tillsammans med agenter.

Och det gör det verkligen.

Jag såg framför allt projektet som ett test av webbutvecklingens nuvarande läge. För att se hur mycket som fortfarande beror på en människa och hur mycket som redan kan göras med AI. Därför använde jag det rekommenderade ramverket.

Självklart läste jag på för att förstå om det passade det jag ville göra. Ur den researchen föddes den här artikeln, där jag berättar vad du behöver veta för att våga prova. Och lite till.

Men innan vi går in på saken, ett par småsaker:

Det första är att jag blev väldigt imponerad av dess HTML first-angreppssätt. Det är precis det jag har predikat i flera år.

Det andra är att i dag, när man utvecklar en webbplats, står ChatGPT eller Claude för allt utom omdömet..

Nu kör vi.

Vad Astro egentligen är

Astro är ett ramverk för att bygga webbplatser, alltså en uppsättning verktyg och riktlinjer som hjälper dig att generera koden till din webbplats.

Varken mer eller mindre.

Det finns många, alla med sina egenheter. Här berättar jag om Astros.

Astro gör det möjligt att arbeta med återanvändbara delar, delade data och mallar. Sedan kombinerar det allt för att skapa webbplatsen.

Med andra ord: tänk på vad du behöver för att bygga ett företags webbplats: sidhuvud, meny, tjänstesidor, fotografier, texter, formulär och sidfot. Du skulle kunna skriva varje sida för hand i HTML, men då skulle du upprepa mycket arbete.

Om du ändrar telefonnumret, lägger till ett menyalternativ eller en länk i footern skulle du behöva ändra det i alla webbplatsens filer. Med Astro slipper du det, eftersom elementen återanvänds.

Och du kommer att säga: som i WordPress. Ja, det stämmer, men här finns ingen databas bakom.

Du skulle också kunna svara att det är som med vilket serverspråk som helst, till exempel PHP, och då skulle jag svara att du inte behöver ha något språk installerat på servern, bara filerna lagrade där.

Som man gjorde från början: en HTML-fil per URL med tillhörande CSS och JS.

Du kan faktiskt använda HTML, CSS och JavaScript eller TypeScript, men också lägga till komponenter från React, Vue eller Svelte om du behöver dem, vilket jag själv inte gör.

Och hur får man då återanvändbara element och många HTML-filer?

Den grundläggande skillnaden: generera webbplatsen innan användaren kommer

För att förstå Astro är det bra att skilja på två tidpunkter i en webbplats liv:

1. När den utvecklas.
2. När någon besöker den.

På en traditionell dynamisk webbplats förbereder servern sidan när den tar emot en begäran. Den kör kod, hämtar nödvändiga data, placerar dem i en mall och skickar resultatet till webbläsaren.

WordPress fungerar till exempel så här: PHP kör applikationen, frågar databasen och använder temat och plugins för att generera sidan. Ja, cachen kan spara ett svar och återanvända det, så hela processen behöver inte upprepas vid varje besök. Det viktiga är att förstå att det finns en applikation som kan skapa svaret medan webbplatsen körs.

Med Astro däremot kan du göra det arbetet innan du publicerar. Du förbereder sidorna, genererar filerna och lägger resultatet på webbhotellet. Det kallas en build..

När någon sedan går in på kontaktsidan levererar servern HTML som redan är färdig. Den behöver inte bygga om sidhuvudet, hämta telefonnumret och sätta ihop sidfoten för den besökaren.

Det här arbetssättet kallas SSG, eller statisk webbplatsgenerering. Och det har flera fördelar, bland annat att sådana sajter bokstavligen flyger..

Det finns fler, som jag förklarar i artikeln.

Det jag har berättat hittills räcker för att ge dig en bild av vad vi pratar om om du inte är teknisk. Om du är det går vi från och med nu djupare in i hur ramverket fungerar.

Starkt kaffe för kaffeälskare. Du är varnad.

Låt oss prata om builds

Det första du behöver förstå är att en build inte är något annat än resultatet av en automatiserad process som tar alla filer du har skrivit (kod, bilder, stilar) och omvandlar dem till ett paket som är klart att köras av servern eller webbläsaren..

Det är allt.

Du har alltså en serie kodfiler som gör olika saker. När du kör kommandot för att kompilera builden identifierar Astro sidorna, hämtar innehållet, kör mallarna och förbereder resurserna för att till slut ge dig en komplett statisk webbplats med HTML, CSS och JS (om det behövs)..

Du kan till exempel ha en gemensam mall och åtta tjänsteposter. Builden kombinerar mallen med data för varje post och skapar motsvarande sidor.

I Astro görs detta med kommandot npm run build , som normalt kör astro build. . Webbplatsen som är klar att laddas upp finns i mappen dist och är redo att laddas upp till servern som din domän pekar på.

Hur en sida byggs i Astro

Om du inte är van vid det verkar ordförrådet mer komplicerat än det är. Vi tar en liten företagswebbplats som exempel.

Hur en .astro-fil ser ut

En .astro-fil kan kombinera en koddel med en HTML-liknande mall:

—

const titulo = 'Transporte para tu empresa';

—

<h1>{titulo}</h1>

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

Det som står mellan de två grupperna med bindestreck förbereder data. Under dem finns mallen som använder dessa data. Klammrarna visar var ett värde ska infogas.

Den koden körs när webbplatsen byggs och webbläsaren får en vanlig rubrik med sin text och ett vanligt stycke med innehållet i variabeln titulo.

Komponenter

Elementen som återanvänds.. 

Till exempel kan sidhuvudet vara en komponent. Sidfoten en annan. En mall för hero banner -modulen på tjänstesidorna en tredje. Du sparar dem separat och använder dem på de sidor som behöver dem.

Till exempel kan en sida importera Header.astro och Footer.astro och placera <Header /> i början och <Footer /> i slutet. Astro omvandlar de delarna till motsvarande HTML-markup.

Props

Dessa props är data du skickar till en komponent så att den kan återanvändas med olika innehåll..

Om du har skapat en komponent för hero banner-modulen på tjänstesidor kan du skicka in en titel, beskrivning och bild. Strukturen behåller sin design medan värdena ändras. På så sätt kan hero-modulen för tjänst 1 vara en sak och den för tjänst 2 en annan, med olika innehåll men samma design.

I Astro kan komponenten läsa dessa värden via Astro.props. 

Layouts och slots

En layout är en struktur som delas av flera sidor. Man kan säga att den är som en komponent på en högre nivå: : en komponent är oftast en liten del av sidan, medan layouten omfattar nästan hela sidan..

Den kan innehålla HTML-dokumentet, metadata, sidhuvudet och sidfoten.

En slot är platsen där varje sidas eget innehåll placeras. 

Om du kommer från WordPress kommer det att påminna om mallar som delar sidhuvud och sidfot medan huvudinnehållet varierar mellan URL:er. Det fungerar inte exakt likadant, men fyller en liknande funktion: att slippa bygga om det gemensamma varje gång.

Hur Astro organiserar URL:er

Astro använder ett filbaserat routingsystem. I ett enkelt projekt avgör en sidas plats inuti src/pages dess adress:

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

Det avslutande snedstrecket beror på konfiguration och hosting, men grundrelationen är den här.

Du behöver inte skapa en separat fil manuellt för varje artikel eller tjänst. Det gör att du kan generera många sidor från en mall och en datamängd utan att kopiera samma kod om och om igen.

Var innehållet lagras om Astro inte har någon databas

Att Astro inte kräver en databas betyder att texter och data måste lagras i någon typ av källa; du kan själv välja vilken.

Filer, Markdown, JSON och YAML

På en liten webbplats kan en del text ligga direkt i sidorna. Delade data, som telefonnumret, bör hållas separat så att du inte behöver ändra dem på tjugo ställen.

En artikel kan lagras i Markdown, ett textformat med enkel markering för rubriker, listor och länkar. JSON och YAML används för att organisera data: tjänsteposter, fordonsinformation eller texter per språk till exempel.

Det är olika format för olika behov. Du behöver inte använda alla eller göra om varje mening på webbplatsen till en komplicerad struktur.

Content Collections

Dessa Content Collections, eller innehållssamlingar, hjälper till att organisera uppsättningar av dataposter och definiera deras struktur..

Tänk dig en samling tjänster där varje post måste ha titel, beskrivning och bild. Du kan definiera de reglerna och validera data så att det blir lättare att upptäcka en ofullständig post eller ett värde av fel typ.

Om du känner till innehållstyper och anpassade fält i WordPress kommer idén att organisera poster kännas bekant.

Avancerat innehåll: API:er, CMS och externa databaser

Även om vi genererar statiska webbplatser kan innehållet också komma från ett CMS, ett API eller en databas. Ett API är ett sätt för två system att utbyta information: Astro begär data och det andra systemet levererar dem.

Du kan till och med använda WordPress som källa för artiklar och bygga den publika delen med Astro. Vi återkommer till den kombinationen i Astro vs WordPress..

Den avgörande frågan är när du hämtar den informationen. Om den tas in under builden ändrar en ändring i källan inte den publicerade HTML-koden förrän du genererar om den. Om den hämtas under en förfrågan eller från webbläsaren blir beteendet annorlunda och mer likt traditionella dynamiska sidor.

Vad Astro Islands är

En sida kan ha mycket innehåll som du bara behöver läsa och en liten del som du vill interagera med. Till exempel en offertkalkylator på en tjänstesida. Eller ett formulär..

Arkitekturen med öar gör att den komponenten kan ha sitt eget beteende utan att hela sidan blir en applikation som körs i webbläsaren.

Vad det innebär att hydrera en komponent

Hydrering innebär att lägga till koden för en interaktiv komponent i HTML som redan har genererats, så att den kan reagera på användarens handlingar.

Kalkylatorn eller formuläret kan visas när sidan laddas och därefter aktivera sin logik.. 

Här pratar vi om klientöar. Astro har också serveröar för att lösa dynamiska delar separat, även om vi inte behöver gå in på dem för att förstå den här första förklaringen.

När webbläsaren behöver JavaScript

Alla interaktioner kräver inte en ö. En länk fungerar med HTML. En enkel rullgardinsmeny kan lösas med HTML och CSS.

En kalkylator som uppdaterar resultat när du ändrar alternativ behöver däremot vanligtvis JavaScript. Och formuläret behöver en integration eller ett serverspråk för att skicka data.

Och här älskar jag Astros angreppssätt: beslutet tas utifrån den funktion du vill erbjuda, inte utifrån den slitna idén att en modern webbplats måste ladda en hel applikation..

Astro försöker skicka noll JavaScript som standard

Observera att vi inte blandar ihop saker: vi pratar om webbplatsen som användaren ser.. 

För Astro använder JavaScript för att arbeta och kompilera, men .astro -komponenter behöver inte skicka sin förberedande kod till webbläsaren. 

De script du lägger till, öar du hydrerar och externa verktyg kan däremot lägga till JavaScript. En chatt, en analyticsplattform (GA4) eller en inbäddad video behöver det.

Alltså: ”noll JavaScript som standard” är utgångspunkten, ingen skyldighet.

Och som jag berättar längre ner passar det här till exempel väldigt bra för hur jag utvecklar företagswebbplatser.

Astro kan vara statiskt, dynamiskt eller en kombination av båda

Bra, hittills har jag fokuserat på ett enda angreppssätt, men det finns två möjligheter.

SSG

Det vi har sett hittills: sidan genereras före besöken, under builden. 

Det är perfekt när innehållet kan vara detsamma för alla fram till nästa publicering. Alltså för sidor som inte ändras särskilt mycket.

SSR

Sidan genereras på servern vid behov. Den kan använda information som inte finns under builden, till exempel data kopplade till en session. 

Nu duger inte vilken server som helst: du behöver en kompatibel körmiljö och rätt adapter.

Hybridrendering

Du kan kombinera förrenderade sidor och sidor som genereras vid behov. Till exempel hålla de publika sidorna färdiga och hantera en privat del på servern.

Vilken roll Node.js och Vite spelar

Node.js gör det möjligt att köra JavaScript utanför webbläsaren. I ett vanligt Astro-projekt används det i utvecklingen och när builden skapas, där npm hjälper till att hantera paket och kommandon. För en statisk webbplats behöver Node.js inte köras på produktionsservern där builden ligger.

Vite är en motor som används av många moderna ramverk. Den är en del av maskineriet Astro använder för att arbeta med filer och erbjuda utvecklingsmiljön. 

Det räcker för att du ska få en uppfattning.

Hur ett Astro-projekt är organiserat

När du öppnar ett projekt ser du mappar som inte är sidor och filer som inte publiceras. Den här lilla kartan hjälper dig att skilja dem åt.

src

Innehåller källkoden: sidor, komponenter, layouts och andra arbetsfiler. Det är här en stor del av webbplatsen byggs.

public

Innehåller resurser som levereras utan den vanliga bearbetningen av importerade filer: till exempel en robots.txt eller vissa bilder. Allt du lägger här blir offentligt, så det är ingen plats för inloggningsuppgifter.

package.json

Beskriver projektet, dess beroenden och dess script. Där definieras vad kommandon som npm run build kör. Beroendenas lockfil hjälper till att behålla specifika versioner så att installationen kan upprepas.

node_modules

Det är mappen där paketen som projektet behöver installeras. Den byggs normalt upp igen från beroendefilerna och sparas inte i sin helhet i Git.

dist

Innehåller produktionsutdata efter builden. För en statisk webbplats hittar du här filerna som är redo att publiceras.

Vad webbläsaren och Google faktiskt laddar

Jag säger det en gång till för dem längst bak: webbläsaren får inte ditt projekt så som du ser det i editorn. Den får HTML och de resurser som behövs för att visa och använda sidan.

En sökmotor som begär den URL:en får HTML-koden, oavsett om du förberedde den under builden eller genererade den på servern. Det garanterar inte att den indexeras eller rankar bra: innehåll, länkar och inställningar för crawling och indexering spelar fortfarande roll, men enligt min erfarenhet går det att optimera det som tas emot väldigt, väldigt bra.

Idén jag vill att du tar med dig är den här: alla dessa mallar, samlingar och komponenter finns till för att producera en webbplats som fortfarande använder de vanliga teknikerna. Astro styr skapandet av webbplatsen; den resulterande HTML-koden tas emot av en webbläsare.

Slutsats: vilka typer av webbplatser Astro passar för

Det här arbetssättet passar bra för webbplatser där innehållet inte ändras särskilt mycket:

• Företagswebbplatser.
• Portföljer
• Landningssidor.

Jag skulle inte rekommendera det för tidskrifter, bloggar och webbplatser där mycket innehåll skapas eller där flera innehållsskapare arbetar. Där föredrar jag fortfarande WordPress framför Astro..

Om du gillar angreppssättet och vill veta mer kan du fortsätta läsa om Astros fördelar och nackdelar..

Och om du hellre vill omsätta det i ett komplett projekt har jag tagit fram processen för att skapa en webbplats för ett lokalt företag med AI, med mitt senaste projekt som exempel.

Jag garanterar att när du väl har provat kommer du inte vilja gå tillbaka.