Toen ik voor de website van Bits+Bites een framework zocht kwam ik uit op Hugo - een framework om statische sites te genereren. Ik sta nog steeds vierkant achter die keuze. Voor de doorontwikkeling van een receptensite liep ik echter toch tegen wat beperkingen van Hugo aan. Op zoek naar een ander framework kwam ik Astro tegen, een soort hybride framework waarbij je per component kunt kiezen of deze statisch gegeneerd of dynamisch op een server gerenderd moet worden. De doorontwikkeling van Bits+Bits, Plantproef.nl, is in Astro gebouwd en inmiddels al in een vrij vergevorderd stadium (maar natuurlijk nooit af). Tijd dus om Hugo en Astro eens met elkaar te vergelijken.

Concepten

Deze post bevat nogal wat jargon. Ben je bekend met termen als statische site generatoren en front matter, sla deze paragraaf dan gerust over.

Statische Site Generator

Een statische site generator, of Static Site Generator in het Engels (SSG), genereert op basis van tekstbestanden een website in HTML. Door middel van templates wordt de informatie uit de tekstbestanden in de juiste layout geplaatst. De meeste SSG’s accepteren Markdown als input. Doordat alle HTML al gegeneerd op de server staat, resulteert dit in ontzettend snelle website. Hugo is een voorbeeld van een SSG, maar is zeker niet de enige. Bekende andere voorbeelden zijn Jekyll, Eleventy en Gridsome.

Server Side Rendering

Anders dan bij een statische site, waarbij alle HTML al kant-en-klaar op een server staat, wordt bij Server Side Rendering (SSR) de HTML pas gegeneerd op het moment dat een bezoeker een pagina aanvraagt. Hierdoor kan de HTML aangepast worden aan de input van een bezoeker, iets wat bij een statische site niet mogelijk is. Dit geeft veel meer flexibiliteit, omdat het mogelijk wordt om met een database te communiceren. Dit maakt het mogelijk om complexere websites te maken met interactie met de gebruiker. Bij een statische site is het bijvoorbeeld niet mogelijk om gebruikers te laten inloggen, terwijl dit bij SSR wel mogelijk is.

Markdown

Markdown is een markup taal die ook goed leesbaar is zonder formatting. Zo kun je woorden dikgedrukt maken door ze tussen twee ** te plaatsen. Een beknopt voorbeeld:

# Titel

## Subtitel

Dit is een tekst met een **dikgedrukt** woord. 
Een [link](https://www.google.nl) ziet er zo uit. 

Naast dat het prima leesbaar is zonder dat het daadwerkelijk geformat wordt, laat Markdown zich ook goed omzetten naar HTML.

Front Matter

Met Front Matter kun je metadata toevoegen aan een Markdown document. Hierdoor blijven content en metadata gescheiden. Hier kun je bijvoorbeeld informatie kwijt als de titel van de pagina, een omschrijving, afbeelding en andere metadata die je in wilt zetten voor SEO. De metadata is ook te gebruiken om de werking van je site aan te passen, bijvoorbeeld door expliciet een andere layout voor een pagina te gebruiken.

Content Management Systeem

Een Content Management Systeem (CMS) is een systeem om content in te genereren en op te slaan. Vaak heb je hierbij een gebruikersinterface en een database, al zijn er ook systemen die de content opslaan in Markdown (zoals Statamic). Een CMS maakt het makkelijker voor niet-technische gebruikers om content toe te voegen, maar biedt ook voordelen op het gebied van koppelen van informatie.

Hugo

The world’s fastest framework for building websites

Hugo is een Static Site Generator (SSG) gebouwd in Go, een programmeertaal ontwikkeld door Google.

De content wordt geschreven in [Markdown], wat wordt omgezet naar HTML en CSS op basis van een template. Er zijn veel kant-en-klare thema’s, maar het is ook mogelijk om zelf een thema te maken.

Voordelen van Hugo

Veel ingebouwd

Hugo is framework waarbij veel out-of-the-box werkt. Hierdoor kun je met minimale inspanning heel snel een website of blog online plaatsen. Hugo bouwt onder andere automatisch een RSS-feed en Sitemap voor je. Ook tags zijn heel eenvoudig te implementeren.

Markdown render hooks

Wat ik me pas toen ik in Astro ging bouwen ging beseffen was hoe handig de Markdown render hooks in Hugo zijn. Hierdoor is het mogelijk om aan te passen hoe bepaalde elementen van de blog gerenderd worden. Zo kun je bijvoorbeeld een aangepaste render hook maken voor het renderen van afbeeldingen, die in combinatie de ingebouwde Image rendering automatisch geoptimaliseerd kunnen worden. Andere mogelijke render hooks zijn links, codeblocks en headings.

Shortcodes

Omdat er soms beperkingen zijn aan het gebruik van Markdown heeft Hugo Shortcodes geïntroduceerd. Een shortcode is een kleine snippet, die gegevens die je invoert omzet aan de hand van een vooraf gedefinieerd template.

Je kunt zelf shortcodes definiëren, maar er zijn ook al een aantal shortcodes ingebouwd.

Interne links

Een ingebouwde shortcode in Hugo is om interne links toe te voegen. Hierdoor kun je naar een bestand verwijzen, waarna Hugo dit automatisch omzet naar de juiste url. Dit zorgt ervoor dat je altijd de url altijd in het juiste formaat is. Hierdoor voorkom je het vergeten of onterecht toevoegen van een trailing slash / wat anders zou resulteren in redirects en de snelheid van je website beinvloedt.

[Neat]({{< ref "blog/neat.md" >}})
[Who]({{< relref "about.md#who" >}})

Learning curve

Een wat vaker gehoorde klacht op internet is dat de template-taal van Hugo een beetje wonky is. Het is ook een beetje wennen na vooral Python gewend te zijn, bijvoorbeeld met de Jinja template-taal.

{% if a == b %}
 <p>a is gelijk aan b</p>
{% endif %}

In Hugo is de syntax net even anders:

{{ if eq $a $b }}
 <p>a is gelijk aan a</p>
{{ end }}

Dit is in het begin vooral verwarrend wanneer er verschillende statements achter elkaar komen:

{{ if or (eq $a $b) (eq $a $c)}}
 <p>a is gelijk aan b of aan c</p>
{{ end }}

Uiteindelijk heb ik een zwak voor rare template-taaltjes (Apache Velocity kostte me echt veel meer moeite om onder de knie te krijgen) en vind ik de template-taal in Hugo nog steeds erg leuk.

Nadelen van Hugo

Je zit vast aan de structuur van Hugo

Om een website te kunnen genereren is het belangrijk dat je je vasthoudt aan de structuur van Hugo. Alles moet in de juiste mappen geplaatst worden, anders werkt het niet.

Beperkingen opmaak blogposts

Een ander nadeel van Hugo is dat de opmaak van de body niet heel flexibel is. Je hebt wat mogelijkheden met render hooks en shortcodes, maar niet veel meer dan dat. Dit nadeel is net per se specifiek voor Hugo, maar geldt voor meerdere SSG’s die op basis van Markdown sites genereren.

Tailwind CSS

Tailwind CSS maakt het een stuk makkelijker om je website vorm te geven dan wanneer je plan CSS gebruikt. Tailwind CSS gebruiken met een Hugo website is alleen niet per se vanzelfsprekend. Er zijn veel blogposts te vinden die het allemaal net even anders doen. Veel van die blogposts zijn ook erg verwarrend. Deze post op sbero.dev biedt mogelijk een betere methode dan die ik eerder heb beschreven.

Geen koppeling CMS / database

Het is niet mogelijk om Hugo aan een CMS te koppelen, om daar content uit te halen in plaats van uit Markdown. Afhankelijk van het doel van de website hoeft dit niet per se een nadeel te zijn. Voor Plantproef wilde ik wel op zijn minst de optie hebben om het te kunnen koppelen aan een CMS.

Astro

The web framework that scales with you

Terwijl Hugo puur een statische site generator is, is Astro een meer hybride systeem. Het is net als Hugo in te zetten als SSG, maar je kunt er ook voor kiezen om het te gebruiken als Server Side Renderen. Daarnaast is het ook hybride te gebruiken, waarin bepaalde delen van je website statisch gegeneerd worden terwijl je dynamische componenten door een server kunt laten renderen.

Voordelen van Astro

Meer mogelijkheden opmaak blogposts

Bij Hugo heb je weinig flexibiliteit in de uiteindelijke opmaak van blogposts. Dit is redelijk inherent aan het gebruik van Markdown. Astro ondersteunt naast Markdown ook het MDX- formaat, wat het mogelijk maakt om Javascript aan je Markdown toe te voegen. Voor nog meer flexibiliteit is het ook mogelijk om content in Astro-bestanden te schrijven.

Betere koppeling Tailwind CSS

De implementatie van Tailwind is bij Astro veel vanzelfsprekender dan bij Hugo. In de documentatie van Astro staat duidelijker omschreven hoe dit moet, hoe je het configureren en tegen welke problemen je aan zou kunnen lopen.

Astro Islands

De meest unieke feature van Astro zijn denk ik wel Astro Islands. Deze maken het mogelijk om componenten van je website statisch of dynamisch te maken. Met behulp van Astro Islands kan één pagina zowel interactieve als statische islands bevatten. Hierdoor kun je alleen de elementen waarvoor interactie met een database nodige is dynamisch maken, terwijl alle elementen die niet interactief zijn statisch kunnen blijven. Zo heb je aan de ene kant de voordelen van een SSG - een snelle website die makkelijk voor een zoekmachine te crawlen is - terwijl je toch ook met een database kunt communiceren op basis van interactie met de gebruiker HTML kunt genereren.

Koppelen CMS / database

Een belangrijk voordeel van Astro is dat je het kunt koppelen aan een CMS en eventueel ook aan andere databases. Ook met die koppeling kun je er nog steeds voor kiezen om een compleet statische site te genereren. Voor mij was dit de belangrijkste reden om Astro als framework te kiezen. Alles opslaan in Markdown werd steeds minder geschikt voor mijn website, omdat ik steeds meer aan elkaar wilde koppelen.

Het is Javascript/Typescript

Of dit daadwerkelijk voor iedereen een voordeel is laat ik achterwege. Voor veel frontend-developers is Javascript echter een taal waar ze al heel erg bekend mee zijn. Dit maakt het makkelijker om in een framework te stappen dat ook Javascript gebruikt, omdat je geen nieuwe concepten hoeft te leren. Je hebt daarbij zelf de keuze of je Javascript of Typescript gebruikt. Ook voor componenten kun je kiezen of je Astro-componenten wilt maken, of componenten gebouwd in een ander framework zoals React of Vue wilt gebruiken.

Nadelen van Astro

Alles zelf doen

Terwijl bij Hugo veel is ingebouwd, moet je bij Astro veel meer zelf doen. Gelukkig zijn er wel verschillende plugins die het makkelijker maken om dit te doen. Zaken als een sitemap en rss-feed zul je zelf moeten toevoegen. Een voordeel is dan wel weer dat je flexibeler bent in hoe deze worden opgebouwd.

Geen ingebouwde interne links

Een van de dingen waar ik bij Hugo wel over te spreken was, was hoe interne links worden gegenereerd. Hugo zorgt ervoor dat je een url in het juiste format krijg, met of zonder trailing slash. In Astro ben je zelf verantwoordelijk voor het maken van interne links.

Onduidelijke scheiding code - content

Een ding wat ik vrij snel minder vond aan Astro was dat de scheiding tussen content en code duidelijker kan. In Astro plaats je zowel je content als je code in de map src. Afhankelijk van hoe je Astro gebruikt (gebruik je wel of geen content collections) plaats je content in src/content of src/pages. Je afbeeldingen en andere assets plaats je in src/assets. In src bevinden zich bij mij nu de volgende submappen:

• assets
• components
• content
• layouts
• lib
• pages

assets, content en pages zijn dus submappen die iets te maken hebben met de content, waarbij pages zowel pagina-definities als content kan bevatten. In andere submappen van src plaats je je layouts, componenten en eventuele scripts. Naarmate de website groeit wordt deze mengeling steeds vervelender. Hugo lost dit wat mij betreft eleganter op: alle content zit in de map content, terwijl je thema-definitie in themes zit.

Aanpassen Markdown rendering

Hoewel Astro als voordeel heeft dat je flexibel bent in het gebruik van markdown, mdx of astro-bestanden voor je content, kent dit ook nadelen. Dit is deels ook gerelateerd aan het probleem dat Astro van je verwacht dat je heel veel zelf doet.

Terwijl je in Hugo voor het renderen van Markdown bepaalde elementen kunt aanpassen door middel van render hooks, kan dit bij Astro door het gebruiken van remark-rehype plugins. Als een plugin al bestaat heb je geluk, anders zul je er zelf een moeten schrijven. Dit is misschien niet zo ingewikkeld als je veel ervaring hebt met Javascript. Dan zou het zelfs als voordeel gezien kunnen worden. Als je hier - net als ik - zonder al teveel kennis van Javascript aan begint kan dit wel wat ingewikkeld zijn.

Nieuw platform

Astro is een relatief nieuw framework en bestaat sinds 2021. Dit is veel korter dan Hugo, waarvan de eerste versie al in 2013 is gemaakt. Hierdoor verandert er nog relatief veel aan het framework. Aan de ene kant is dit natuurlijk juist positief, omdat er veel extra features en verbeteringen worden doorgevoerd. Aan de andere kant betekent het ook dat je soms gedwongen bent om bepaalde onderdelen van je site aan te passen of dat de documentatie soms achterhaald is.

Veel Javascript

Voor mij geldt het voordeel van Javascript eigenlijk niet. Toen ik begon te bouwen had ik niet heel veel ervaring met Javascript, en dan is de hoeveelheid Javascript die nodig is om een website in Astro te bouwen wel flinke hobbel.

Conclusie

Beide frameworks hebben hun eigen voors en tegens en allebei zijn ze prima geschikt om een website in te maken. Of Hugo of Astro geschikter is hangt vooral af van de vereisten van de website, en voor een deel ook aan de voorkeuren van de developer.

Hugo is perfect voor simpele statische sites waarbij geen interactie met de gebruiker nodig is. Er is veel out-of-the-box ingebouwd, waardoor je erg snel een website online kunt hebben.

Met Astro kun je ook snel een site online hebben, al zul je er wel iets meer voor moeten doen. Daarnaast is het wel veel flexibeler en krachtiger, en daardoor ook geschikt om complexere websites mee te bouwen. Als je al bekend bent met Javascript is het waarschijnlijk een goede keuze, omdat een template maken dan veel vanzelfsprekender zal zijn.