Voor- en nadelen van Astro: wanneer is het de moeite waard?

Wie websites zonder onderhoud heeft verkocht, weet hoe vaak je de klant vertelt dat je een supersimpel CMS oplevert waarmee hij moeiteloos grote en kleine wijzigingen kan doorvoeren.

Bij de offerte vindt de klant dat geweldig, maar na oplevering verandert hij maandenlang niets. En als hij uitzonderlijk iets wil aanpassen, mailt hij jou om het te doen.

Logisch: hij richt zich op zijn bedrijf en wil vooral dat de website klanten oplevert. Helemaal prima.

Omdat ik dit zo vaak heb gezien, dacht ik altijd dat WordPress fantastisch is, vooral voor de ontwikkelaar, omdat het onderhoud vergt dat niet altijd nodig zou moeten zijn.. 

Daarom dacht ik dat er alternatieven moesten bestaan. Andere routes die ik tot nu toe niet had gevonden.

Want met websites in pure HTML kost zelfs de kleinste wijziging, zoals het telefoonnummer van de klantenservice, behoorlijk wat tijd. Bovendien heb je vaak ingewikkelde functies nodig waarvoor in principe een servertaal vereist is.

Ja, PHP is een optie, met zijn includes en mogelijkheden. Maar ontwikkelen wordt een stuk ingewikkelder dan met WordPress. Om nog maar te zwijgen van hosting waarop die taal geïnstalleerd moet zijn en de noodzaak om die taal te blijven bijwerken.

Maar kort geleden ontdekte ik Astro. En ineens viel alles op zijn plek.

Astro's filosofie: eerst HTML, JavaScript alleen wanneer nodig

Als je de tool nog niet kent, kun je beginnen door te begrijpen wat Astro is en hoe het werkt, vooral technisch. Hier kijken we naar de praktische gevolgen van de architectuur..

De aanpak is: content als HTML aanbieden en browsercode bewaren voor onderdelen die die echt nodig hebben. Naast statische generatie ondersteunt het overigens ook rendering op aanvraag.

Laten we bekijken wat dat betekent.

De voordelen van Astro

Eerst een belangrijk onderscheid: sommige voordelen gelden overal, andere alleen voor bepaalde soorten websites.

Ik loop ze langs.

Prestaties dankzij de architectuur

Bij een dienstenpagina voorkomt het aanbieden van een kant-en-klaar document verwerking tijdens het bezoek. Je hebt geen server nodig om ongewijzigde inhoud op te bouwen; een opgeslagen HTML-bestand terugsturen volstaat.

Dat is een prima basis om (heel) snel te laden. Vooral met geoptimaliseerde afbeeldingen (hallo, webp), geoptimaliseerde CSS en een goede levering van bestanden.

Het voordeel is dat je begint met een lichte structuur en vervolgens heel bewust alleen toevoegt wat je werkelijk nodig hebt..

Heel weinig JavaScript in de browser

Astro probeert alle overbodige JavaScript te vermijden, want minder JavaScript scheelt niet alleen downloadverkeer maar ook rekenwerk op het apparaat. Op een pc is dat meestal geen probleem, maar op een telefoon, vooral een goedkope, wel: die moet ontvangen code verwerken en uitvoeren naast alles wat hij verder doet.

Op een informatieve website is veel logica meesturen die nauwelijks iets voor bezoekers toevoegt een onnodige verspilling van middelen.

Astro daarentegen maakt het eenvoudig om kleine interactieve hulpmiddelen te integreren die echt nodig zijn. Dat voordeel blijft behouden zolang je let op wat je toevoegt.

Schone HTML en een goede uitgangspositie voor SEO

Als de hoofdinhoud als HTML beschikbaar is, is die makkelijker toegankelijk.

Daarnaast is het relatief eenvoudig om de best practices voor SEO te volgen, omdat je een duidelijke structuur van koppen, links en secties kunt maken.

Kleiner aanvalsoppervlak

Dit is een mooi voordeel als je onderhoud wilt vermijden.

Op een statisch gepubliceerde site draaien in het openbare deel geen CMS en geen database. Er zijn minder blootgestelde functies die je moet beschermen..

Dat verkleint bepaalde risico's ENORM, al wordt het project er niet onkwetsbaar door. Je hostingaccount, GitHub-repository en gekoppelde diensten moeten nog steeds worden beveiligd. En als je een formulier met een backend gebruikt, moet die backend invoer controleren en misbruik beperken. Het mooie is dat sommige sites dat vrijwel nooit nodig hebben.

Eenvoudige, goedkope hosting

Nog een algemeen voordeel.

Statische bestanden aanbieden vraagt meestal minder infrastructuur dan een applicatie met database en servertaal draaien. Voor kleine projecten kan een statische site passen binnen een gratis of goedkoop pakket, afhankelijk van de aanbieder.

Een van de grote voordelen is zelfs dat je een websitebuild gratis op CloudFlare kunt plaatsen en dus niets aan hosting betaalt. Ja, die kosten vervallen helemaal.

Je moet websitehosting wel onderscheiden van de rest van het project:

• Voor de domeinnaam blijf je betalen.
• E-mail kan ook gratis zijn..
• Gebruik je API's, van Meta of andere partijen, dan hangen kosten af van het gebruik.

Kortom: zonder traditionele server is niet het hele systeem gratis, maar bij bedrijfswebsites verdwijnt wel de grootste kostenpost.

Componenten zonder van de hele site een SPA te maken

Een SPA (Single Page Application) is een applicatie waarbij een groot deel van de navigatie en de interface afhankelijk is van browsercode. Voor bepaalde producten, zoals sociale netwerken en hun feeds, kan dat zinvol zijn, maar een dienstenwebsite heeft het zelden nodig.

Astro maakt het echter mogelijk componenten en gedeelde structuren opnieuw te gebruiken waar dat nodig is, zonder dat de hele site als SPA moet functioneren. Je past een gemeenschappelijk blok één keer aan en blijft pagina's als gewone documenten serveren.

Flexibiliteit met content

Dat je geen CMS nodig hebt, betekent niet dat je er geen kunt toevoegen.

Je kunt voor een bedrijfswebsite beginnen met statische bestanden en een CMS koppelen als je bijvoorbeeld wilt gaan bloggen. Ook kun je koppelen met systemen die het bedrijf al gebruikt en daar gegevens uit ophalen.

Die vrijheid biedt verschillende oplossingen voor allerlei websites.

Koppeling met Git

Omdat alleen bestanden nodig zijn en geen database, integreert Astro uitstekend met Git.

Door de projectgeschiedenis in Git te bewaren, zie je makkelijker wat er is veranderd, kun je vóór publicatie testen en een eerdere versie herstellen.

Als AI code ontwikkelt, is die traceerbaarheid bijzonder nuttig: je kunt een specifieke wijziging controleren zonder erop te vertrouwen dat de assistent zich herinnert wat hij deed.

Scheiding tussen frontend en externe diensten

Ja, HTML is prachtig, maar met alleen HTML laat je geen formulier werken waarvan de antwoorden bij jou terechtkomen. Daarvoor heb je een server nodig.

Het voordeel is dat je vanuit HTML de API van diensten zoals Zoho Mail kunt koppelen en antwoorden naar het e-mailadres van je keuze kunt laten sturen. En dat helemaal gratis.

Als je deze tool al voor je zakelijke e-mail gebruikt, hoef je niets meer aan je stack toe te voegen.

De grootste nadelen van Astro

Nu de zwakke punten van het framework, waardoor het voor bepaalde projecten minder geschikt is.

Geen gebruiksklaar CMS inbegrepen

Als ik een website ga ontwikkelen, is mijn eerste praktische vraag: wie gaat hem bijwerken en onderhouden?

Verwacht de klant een dashboard te openen, een foto te vervangen en te publiceren, dan biedt Astro alleen die ervaring niet. Je moet met bestanden werken of een bewerkingstool toevoegen.

Voor klanten die zelf wijzigingen moeten kunnen maken zonder jou te bellen, is Astro niet de beste optie.

Meer technische keuzes vereist

Je moet bepalen waar teksten komen, hoe wijzigingen worden gepubliceerd, hoe het formulier werkt en wat er gebeurt als een dienst uitvalt.

Met een CMS als WordPress krijg je dat grotendeels standaard.

Het voordeel van Astro is wel dat je zo'n systeem één keer kunt ontwerpen en voor meerdere websites kunt hergebruiken.

Integraties vereisen ontwikkeling

Sommige diensten maken het werk veel eenvoudiger, maar je vindt niet altijd een kant-en-klare oplossing die je installeert en die alles doet wat je nodig hebt, zoals de gebruikelijke CMS-plugins.

Alleen een formulier vormgeven is bijvoorbeeld niet genoeg. Je moet verzending koppelen, fouten afhandelen, inloggegevens beschermen en controleren of berichten aankomen. Reserveringen met tijden, betalingen en annuleringen maken het werk en het aantal beslissingen vele malen groter.

AI kan de uitvoering versnellen, maar je hebt nog steeds iemand nodig die het resultaat kan beoordelen en er verantwoordelijkheid voor neemt.

Minder handig voor redactieteams

Iemand die af en toe publiceert kan (redelijk) goed met Markdown werken. Een team met meerdere auteurs, controles, planning en voortdurend beeldbeheer heeft uitgebreidere redactietools nodig.

Oftewel: een ouderwets CMS.

Je kunt een geschikt CMS boven op Astro zetten, maar waarom zou je dat doen in plaats van gewoon het CMS te gebruiken?

Builds kunnen ingewikkeld worden bij enorme projecten

Bij statische generatie moeten de te publiceren pagina's worden gebouwd. Hoe lang dat duurt, hangt af van het aantal, de manier waarop gegevens worden opgehaald en de verwerking.

Een grote catalogus met veel afbeeldingen of externe verzoeken kan dat proces ingewikkeld maken. Er bestaat geen magisch aantal URL's waarboven Astro onbruikbaar wordt: je moet het project meten en bepalen wat je vooraf bouwt en wat je op aanvraag rendert.

Als een dringende update afhankelijk is van een mislukte build, blijft de oude inhoud online totdat het probleem is opgelost.

Kleiner ecosysteem dan WordPress

Astro heeft integraties en sjablonen, maar biedt niet dezelfde hoeveelheid kant-en-klare oplossingen voor uiteenlopende zakelijke behoeften.

In WordPress vind je vaak verschillende opties voor reserveringen, lidmaatschappen of redactionele workflows. Met Astro moet je mogelijk diensten koppelen of onderdelen zelf ontwikkelen. Dat beïnvloedt ontwikkeltijd, budget en wie het later kan beheren.

Een leercurve voor wie van PHP of WordPress komt

Als je normaal een thema installeert en plugins configureert, komen er nieuwe tools bij: pakketten, repositories, builds en deployments.

Je hoeft niet alles in één keer te beheersen. Maar je moet wel begrijpen hoe de bestanden die je bewerkt uiteindelijk live komen. Anders laat je AI iets aanpassen, zie je het lokaal en denk je dat het al op de echte website staat.

Niet elk project past bij een statische architectuur

Al het voorgaande komt hierop neer.

Een redelijk stabiele openbare pagina en een dashboard met persoonlijke realtimegegevens hebben verschillende behoeften.

Astro kan serverfuncties en dynamische mogelijkheden toevoegen, maar misschien lost een ander platform het geheel beter op. Het gaat er niet om of Astro het kan, maar of het verstandig is.

Verduidelijking van Astro's beperkingen

Ik heb dit al door het artikel heen besproken, maar vat het hier nog eens samen.

Geen ingebouwd CMS betekent niet dat je geen CMS kunt gebruiken

Je kunt een editor en een contentbron toevoegen. De echte beperking is dat je ze moet kiezen, integreren en onderhouden, met alle kosten van dien.

Geen database nodig betekent niet dat je er geen kunt gebruiken

Voor een eenvoudige site verplicht Astro geen database.

Als je gebruikers, reserveringen of veranderlijke gegevens moet opslaan, kun je een database koppelen. Sleutels en gevoelige queries moeten in een veilige serveromgeving blijven.

Statische generatie betekent niet dat Astro alleen statische sites kan leveren

Je kunt strategieën en diensten combineren.

Een vooraf gemaakte pagina kan een formulier naar een backend sturen. Openbare content en berichtverwerking zijn verschillende taken.

JavaScript tijdens ontwikkeling gebruiken betekent niet dat alles naar de browser gaat

Voor de laadtijd telt wat de bezoeker ontvangt.

Een deel van de code wordt gebruikt om de pagina op te bouwen en draait niet tijdens het bezoek. Als je die momenten verwart, beoordeel je het werkelijke gewicht van de site verkeerd.

Wanneer ik Astro zou kiezen

Nu waar het om draait.

Ik zou Astro overwegen voor:

• Een bedrijfswebsite.
• Een portfolio.
• Documentatie.

Op voorwaarde dat:

• De pagina's redelijk stabiel zijn.
• Niemand behalve ik ze bewerkt.
• Ik goede prestaties wil.
• Lage kosten (geen server betalen).
• En mijn stack AI-ondersteunde ontwikkeling en Git-integratie omvat.

Wanneer ik Astro niet zou kiezen

Ik zou het niet gebruiken als:

• De klant zelf wijzigingen moet kunnen aanbrengen.
• De frontend voortdurend verandert.
• De blog het middelpunt van de website wordt.
• Voor een tijdschrift.
• Voor een webwinkel.
• Voor een ledenomgeving.

Kortom, wanneer een CMS het werk eenvoudiger maakt.

Conclusie: Astro is niet altijd beter, het hangt van het project af

Ik ben dol op Astro's aanpak. Hier zoek ik al lang naar: je kunt veel websites met statische content bouwen met een structuur die heel, heel nauw aansluit op wat ze nodig hebben.

Bovendien werkt het geweldig samen met AI om bijna alles te ontwikkelen.

Maar je moet ook kijken naar het leven van de website na oplevering.

Als de klant de site kan onderhouden, de integraties geregeld zijn en de content erbij past, is het een heel interessante optie.

Zoals je waarschijnlijk wel dacht, is de vergelijking die ik per project het vaakst maak Astro vs WordPress. In het gelinkte artikel leg ik uit hoe je beslist op basis van het hele traject, van bewerking tot onderhoud en het budget van de klant.