Wat Astro is, de technische aanpak en hoe het werkt

Tot voor kort was het voor mij — net als voor bijna iedereen — gebruikelijk om voor een bedrijfswebsite terug te vallen op WordPress. Om voor de hand liggende redenen: het is eenvoudig, bijna alles wat je nodig hebt is al ontwikkeld en na vele jaren is mijn workflow erg snel.

Maar bij mijn laatste project, de website van Rondabus, heb ik Astro gebruikt. 

Waarom?

Het werd aanbevolen in een AI-nieuwsbrief die ik volg, omdat het volgens hen heel goed met agents integreert.

En dat doet het zeker.

Ik heb het project vooral opgevat als een test van de huidige stand van webdevelopment. Om te zien hoeveel nog van een mens afhangt en hoeveel al met AI kan. Daarom gebruikte ik het aanbevolen framework.

Natuurlijk heb ik me ingelezen om te begrijpen of het geschikt was voor wat ik wilde. Uit die documentatie is dit artikel ontstaan, waarin ik vertel wat je moet weten om ermee aan de slag te durven. En nog wat meer.

Maar voordat we echt beginnen, twee kleine dingen:

Ten eerste was ik erg enthousiast over de HTML first-aanpak. Dat is precies wat ik al jaren verkondig.

Ten tweede geldt vandaag de dag bij het ontwikkelen van een website: afgezien van beoordelingsvermogen leveren ChatGPT of Claude al het andere..

Nu kunnen we beginnen.

Wat Astro precies is

Astro is een framework om websites te bouwen, oftewel een verzameling tools en richtlijnen die je helpt de code van je website te genereren.

Niet meer en niet minder.

Er zijn er veel, elk met zijn eigen bijzonderheden. Hier leg ik die van Astro uit.

Astro maakt het mogelijk om met herbruikbare onderdelen, gedeelde gegevens en templates te werken. Daarna combineert het alles om de website te produceren.

Met andere woorden: denk aan wat je nodig hebt om een bedrijfswebsite te bouwen: header, menu, dienstenpagina’s, foto’s, teksten, formulier en footer. Je zou elke pagina met de hand in HTML kunnen schrijven, maar dan herhaal je veel werk.

Als je het telefoonnummer wijzigt, een item aan het menu toevoegt of een link in de footer plaatst, zou je dat in alle bestanden van de website moeten aanpassen. Met Astro niet, omdat het elementen hergebruikt.

En je zult zeggen: net als in WordPress. Ja, dat klopt, maar hier zit geen database achter.

Je zou ook kunnen zeggen: net als bij elke servertaal zoals PHP. Daarop zou ik antwoorden dat er op de server geen taal geïnstalleerd hoeft te zijn; alleen de bestanden hoeven er te staan.

Zoals websites oorspronkelijk werden gemaakt: één HTML-bestand per URL, met de bijbehorende CSS en JS.

Je kunt inderdaad HTML, CSS en JavaScript of TypeScript gebruiken, maar ook React-, Vue- of Svelte-componenten toevoegen als je die nodig hebt, wat ik zelf niet doe.

En hoe krijg je herbruikbare elementen en veel HTML-bestanden?

Het fundamentele verschil: de website genereren voordat de gebruiker arriveert

Om Astro te begrijpen, is het handig om twee momenten van een website uit elkaar te houden:

1. Wanneer hij wordt ontwikkeld.
2. Wanneer iemand hem bezoekt.

Bij een traditionele dynamische website bereidt de server de pagina voor wanneer hij een verzoek ontvangt. Hij voert code uit, haalt de benodigde gegevens op, plaatst die in een template en stuurt het resultaat terug naar de browser.

WordPress werkt bijvoorbeeld zo: PHP voert de applicatie uit, raadpleegt de database en gebruikt het thema en de plugins om de pagina te genereren. Ja, de cache kan een antwoord opslaan en opnieuw gebruiken, waardoor niet bij elk bezoek het hele proces hoeft te worden herhaald. Het belangrijke punt is dat er een applicatie bestaat die het antwoord kan maken terwijl de website draait.

Met Astro daarentegen kun je dat werk al vóór publicatie doen. Je bereidt de pagina’s voor, genereert de bestanden en zet het resultaat op de hosting. Dat heet een build..

Wanneer iemand vervolgens de contactpagina opent, levert de server HTML dat al klaar was. Hij hoeft voor die bezoeker niet opnieuw de header op te bouwen, het telefoonnummer op te halen en de footer samen te stellen.

Deze manier van werken heet SSG, oftewel static site generation. En die heeft verschillende voordelen, zoals dat zulke sites letterlijk vliegen..

Er zijn er meer, die ik in het artikel uitleg.

Wat ik tot nu toe heb verteld, is genoeg om je een idee te geven waar we het over hebben als je niet technisch bent. Ben je dat wel, dan gaan we vanaf hier dieper in op hoe het framework werkt.

Sterke koffie voor koffieliefhebbers. Je bent gewaarschuwd.

Laten we het over builds hebben

Het eerste wat je moet begrijpen, is dat een build niets meer is dan het resultaat van een geautomatiseerd proces dat alle bestanden die je hebt geschreven (code, afbeeldingen, stijlen) pakt en omzet in een pakket dat klaar is om door de server of webbrowser te worden uitgevoerd..

Dat is alles.

Je hebt dus een reeks codebestanden die verschillende dingen doen. Wanneer je het commando uitvoert om de build te compileren, identificeert Astro de pagina’s, haalt de content op, voert de templates uit en bereidt de resources voor om je uiteindelijk een complete statische website te geven, met HTML, CSS en JS (als dat nodig is)..

Je kunt bijvoorbeeld één gemeenschappelijk template en acht dienstenfiches hebben. De build combineert het template met de gegevens van elke fiche en produceert de bijbehorende pagina’s.

In Astro doe je dat met het commando npm run build , dat normaal gesproken astro build. uitvoert. De website die klaar is om te uploaden staat in de map dist en is klaar om naar de server te worden geüpload waar je domein naar verwijst.

Hoe een pagina in Astro wordt opgebouwd

Als je dit niet gewend bent, klinkt de terminologie ingewikkelder dan ze is. Laten we het bekijken aan de hand van een kleine bedrijfswebsite.

Hoe een .astro-bestand eruitziet

Een .astro-bestand kan een codegedeelte combineren met een HTML-achtig template:

—

const titulo = 'Transporte para tu empresa';

—

<h1>{titulo}</h1>

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

Wat tussen de twee groepen streepjes staat, bereidt de gegevens voor. Daaronder staat het template dat ze gebruikt. De accolades geven aan waar een waarde moet worden ingevoegd.

Die code wordt uitgevoerd wanneer de website wordt gebouwd en de browser ontvangt een normale kop met tekst en een normale alinea met de inhoud van de variabele titulo.

Componenten

De elementen die worden hergebruikt.. 

De header kan bijvoorbeeld een component zijn. De footer een andere. Een template voor de hero banner van dienstenpagina’s kan weer een andere zijn. Je bewaart ze apart en gebruikt ze op de pagina’s die ze nodig hebben.

Een pagina kan bijvoorbeeld Header.astro en Footer.astro importeren en <Header /> aan het begin en <Footer /> aan het einde plaatsen. Astro zet die onderdelen om in de bijbehorende HTML-markup.

Props

De props zijn de gegevens die je aan een component doorgeeft zodat je dezelfde component met andere content kunt hergebruiken..

Als je een component hebt gemaakt voor de hero-banner-module op dienstenpagina’s, kun je er een titel, beschrijving en afbeelding aan doorgeven. De structuur behoudt zijn ontwerp terwijl de waarden veranderen. Zo kan de hero-module van dienst 1 iets anders zijn dan die van dienst 2, met andere content maar hetzelfde ontwerp.

In Astro kan de component die waarden uitlezen via Astro.props. 

Layouts en slots

Een layout is een structuur die door meerdere pagina’s wordt gedeeld. Zie het als een component op steroïden: : een component is meestal een klein deel van de pagina, terwijl de layout praktisch de hele pagina omvat..

Hij kan het HTML-document, metadata, de header en de footer bevatten.

De slot is de plek waar de eigen content van elke pagina wordt geplaatst. 

Als je uit WordPress komt, doet dit denken aan templates die een header en footer delen terwijl de hoofdcontent per URL verschilt. Het werkt niet precies hetzelfde, maar vervult een vergelijkbare functie: voorkomen dat je het gemeenschappelijke deel telkens opnieuw moet opbouwen.

Hoe Astro URL’s organiseert

Astro gebruikt een bestandsgebaseerd routingsysteem. In een eenvoudig project bepaalt de locatie van een pagina binnen src/pages het adres:

Bestand	Route
src/pages/index.astro	/
src/pages/contacto.astro	/contacto
src/pages/servicios/bodas.astro	/servicios/bodas

De afsluitende slash hangt af van de configuratie en hosting, maar dit is de basisrelatie.

Je hoeft niet handmatig een apart bestand te maken voor elk artikel of elke dienst. Daardoor kun je veel pagina’s genereren vanuit één template en een dataset, zonder steeds dezelfde code te kopiëren.

Waar content wordt opgeslagen als Astro geen database heeft

Dat Astro geen database vereist, betekent dat teksten en gegevens in een of andere bron moeten worden opgeslagen; je kunt zelf kiezen welke.

Bestanden, Markdown, JSON en YAML

Voor een kleine site kan een deel van de tekst rechtstreeks in de pagina’s staan. Gedeelde gegevens, zoals het telefoonnummer, kun je beter apart zetten zodat je ze niet op twintig plaatsen hoeft te wijzigen.

Een artikel kan worden opgeslagen in Markdown, een tekstformaat met eenvoudige markeringen voor koppen, lijsten en links. JSON en YAML dienen om gegevens te organiseren: dienstenfiches, voertuiginformatie of teksten per taal bijvoorbeeld.

Het zijn verschillende formaten voor verschillende behoeften. Je hoeft ze niet allemaal te gebruiken en hoeft niet elke zin op je site in een ingewikkelde structuur te veranderen.

Content Collections

De Content Collections, of contentcollecties, helpen om sets gegevensitems te organiseren en hun structuur te definiëren..

Stel je een verzameling diensten voor waarin elke fiche een titel, beschrijving en afbeelding moet hebben. Je kunt die regels vastleggen en de gegevens valideren, zodat een onvolledige fiche of een waarde van het verkeerde type makkelijker opvalt.

Als je contenttypes en aangepaste velden uit WordPress kent, zal het idee van georganiseerde fiches vertrouwd voelen.

Geavanceerde content: API’s, CMS’en en externe databases

Hoewel we statische websites genereren, kan content ook uit een CMS, API of database komen. Een API is een manier waarop twee systemen informatie uitwisselen: Astro vraagt gegevens op en het andere systeem levert ze.

Je kunt WordPress zelfs gebruiken als bron voor artikelen en het publieke deel met Astro bouwen. Op die combinatie komen we terug in Astro vs WordPress..

De doorslaggevende vraag is wanneer je die informatie ophaalt. Als die tijdens de build wordt opgenomen, verandert een wijziging in de bron het gepubliceerde HTML pas wanneer je het opnieuw genereert. Wordt de informatie tijdens een verzoek of vanuit de browser opgehaald, dan gedraagt het zich anders en meer zoals traditionele dynamische pagina’s.

Wat Astro Islands zijn

Een pagina kan veel content hebben die je alleen hoeft te lezen en een klein deel waarmee je wilt interacteren. Bijvoorbeeld een offertecalculator binnen een dienstenpagina. Of een formulier..

De architectuur met islands maakt het mogelijk dat die component zijn eigen gedrag heeft zonder de hele pagina te veranderen in een applicatie die in de browser draait.

Wat het betekent om een component te hydrateren

Hydrateren betekent dat je de code van een interactieve component toevoegt aan HTML dat al is gegenereerd, zodat die op acties van de gebruiker kan reageren.

De calculator of het formulier kan worden weergegeven wanneer de pagina laadt en daarna zijn logica activeren.. 

Hier hebben we het over client islands. Astro heeft ook server islands om dynamische delen afzonderlijk af te handelen, al hoeven we daar voor deze eerste uitleg niet op in te gaan.

Wanneer de browser JavaScript nodig heeft

Niet elke interactie vereist een island. Een link werkt met HTML. Een eenvoudig uitklapmenu kan met HTML en CSS worden opgelost.

Een calculator die resultaten bijwerkt terwijl je opties wijzigt, heeft daarentegen meestal JavaScript nodig. En het formulier heeft een integratie of servertaal nodig om de gegevens te verzenden.

En hier vind ik de aanpak van Astro geweldig: de beslissing wordt genomen op basis van de functie die je wilt bieden, niet vanuit het afgezaagde idee dat een moderne website een complete applicatie moet laden..

Astro probeert standaard nul JavaScript te versturen

Let op dat we het niet door elkaar halen: we hebben het over de website die de gebruiker ziet.. 

Want Astro gebruikt wel degelijk JavaScript om te werken en te compileren, maar .astro -componenten hoeven hun voorbereidingscode niet naar de browser te sturen. 

Scripts die je toevoegt, islands die je hydrateert en externe tools kunnen wel JavaScript toevoegen. Een chat, analyticsplatform (GA4) of ingesloten video heeft het nodig.

Dus “standaard nul JavaScript” is het uitgangspunt, geen verplichting.

En zoals ik hieronder uitleg, past dat voor mij bijvoorbeeld heel goed bij de ontwikkeling van bedrijfswebsites.

Astro kan niet alleen statisch zijn, maar ook dynamisch of hybride

Goed, tot nu toe heb ik me op één aanpak gericht, maar er zijn twee mogelijkheden.

SSG

Wat we tot nu toe hebben gezien: de pagina wordt vóór de bezoeken gegenereerd, tijdens de build. 

Dat is perfect wanneer de content voor iedereen hetzelfde kan blijven tot de volgende publicatie. Met andere woorden: voor pagina’s die niet vaak veranderen.

SSR

De pagina wordt op aanvraag op de server gegenereerd. Daarbij kan informatie worden gebruikt die tijdens de build niet beschikbaar was, zoals gegevens die aan een sessie zijn gekoppeld. 

Nu volstaat niet zomaar elke server meer: je hebt een compatibele runtime-omgeving en de bijbehorende adapter nodig.

Hybride rendering

Je kunt vooraf gerenderde pagina’s en pagina’s op aanvraag combineren. Je kunt bijvoorbeeld de openbare pagina’s vooraf klaarmaken en een privégedeelte op de server afhandelen.

Welke rol Node.js en Vite spelen

Node.js maakt het mogelijk om JavaScript buiten de browser uit te voeren. In een normaal Astro-project speelt het een rol bij ontwikkeling en bij het bouwen van de build, waarbij npm helpt om pakketten en commando’s te beheren. Bij een statische website hoeft Node.js niet te draaien op de productieserver waar de build wordt gehost.

Vite is een engine die door veel moderne frameworks wordt gebruikt. Het maakt deel uit van de techniek die Astro gebruikt om met bestanden te werken en de ontwikkelomgeving te bieden. 

Genoeg om je een idee te geven.

Hoe een Astro-project is georganiseerd

Wanneer je een project opent, zie je mappen die geen pagina’s zijn en bestanden die niet worden gepubliceerd. Dit kleine overzicht helpt je ze uit elkaar te houden.

src

Bevat de broncode: pagina’s, componenten, layouts en andere werkbestanden. Hier wordt een groot deel van de website gebouwd.

public

Bevat resources die zonder de gebruikelijke verwerking van geïmporteerde bestanden worden geserveerd: bijvoorbeeld een robots.txt of bepaalde afbeeldingen. Alles wat je hier plaatst is openbaar, dus dit is geen plek voor inloggegevens.

package.json

Beschrijft het project, de afhankelijkheden en de scripts. Hier wordt bepaald wat commando’s zoals npm run build uitvoeren. Het lockbestand van de afhankelijkheden helpt specifieke versies vast te houden, zodat de installatie kan worden gereproduceerd.

node_modules

Dit is de map waarin de pakketten worden geïnstalleerd die het project nodig heeft. Normaal wordt hij opnieuw opgebouwd uit de afhankelijkheidsbestanden en niet volledig in Git opgeslagen.

dist

Bevat de productie-output na de build. Bij een statische website vind je hier de bestanden die klaar zijn om te publiceren.

Wat de browser en Google echt laden

Ik herhaal het nog één keer voor de mensen op de achterste rij: de browser ontvangt je project niet zoals jij het in de editor ziet. Hij ontvangt de HTML en de resources die nodig zijn om de pagina te tonen en te gebruiken.

Een zoekmachine die die URL opvraagt, ontvangt de HTML, ongeacht of je die tijdens de build hebt voorbereid of op de server hebt gegenereerd. Dat garandeert niet dat de pagina wordt geïndexeerd of goed scoort: content, links en crawl- en indexeringsinstellingen blijven belangrijk, maar naar mijn ervaring kun je wat er wordt ontvangen heel, heel goed optimaliseren.

Het idee dat ik wil dat je onthoudt is dit: al die templates, collecties en componenten dienen om een website te produceren die nog altijd de vertrouwde technologieën gebruikt. Astro stuurt het maken van de website aan; de resulterende HTML wordt door een browser ontvangen.

Conclusie: voor welk type websites Astro zinvol is

Deze manier van werken past goed bij websites waarvan de content niet voortdurend verandert:

• Bedrijfswebsites.
• Portfolio’s
• Landingspagina’s.

Ik zou het niet aanraden voor magazines, blogs en websites waarop veel content wordt gemaakt of meerdere contentmakers werken. Daarvoor geef ik nog steeds de voorkeur aan WordPress boven Astro..

Als deze aanpak je aanspreekt en je meer wilt weten, kun je verder lezen over de voor- en nadelen van Astro..

En als je het liever in een volledig project toepast, heb ik het proces uitgewerkt om met AI een website voor een lokaal bedrijf te maken, met mijn laatste project als voorbeeld.

Ik garandeer je dat je, zodra je het geprobeerd hebt, niet meer terug wilt.