Na het besluit om aan een website te beginnen komt de vraag: waar ga ik die in bouwen? Dat hangt allemaal af van de eisen die je eraan stelt. Wordt het een site waarbij interactiviteit belangrijk is, of wordt het vooral statisch waarbij de bezoeker alleen maar informatie tot zich moet nemen.

Voor bits+bites had ik het idee dat het een tweeledige site moest worden, een deel voor recepten en een blog over voornamelijk technische zaken die op mijn pad komen, zoals het bouwen van een blog. Interactiviteit is daarbij niet zo belangrijk.

Er zijn veel verschillende web-development frameworks, en zeker voor een blog hoeft het allemaal niet te ingewikkeld. Met bijvoorbeeld Wix of Wordpress heb je zonder al teveel technische ingewikkeldheden vrij snel een website up en running die er ook nog eens goed uitziet. Nu heb ik de slechte eigenschap dat ik technische ingewikkeldheden over het algemeen leuke uitdaging vind, en met standaard-frameworks vaak wat flexibiliteit mis.

Die keuze is niet te maken zonder te weten welke functionaliteit ik van mijn blog verwacht.

• Content creëren in Markdown
• SEO relatief eenvoudig te implementeren
• Goed doorzoekbaar (als er uiteindelijk ook iets te zoeken is)
• Plaatjes makkelijk invoegen en automatisch kleiner maken

Waarom Markdown?

Markdown is een tekstformaat dat eenvoudig converteert naar HTML, maar wat als platte tekst goed leesbaar is. Het zorgt ervoor dat je je vooral kunt focussen op het schrijven, zonder dat je daar een specifieke tekstverwerker voor nodig hebt. Het wordt veel gebruikt om documentatie voor code op bijvoorbeeld GitHub te schrijven.

Naast dat het als platte tekst goed leesbaar blijft, is Markdown ook zo universeel dat het het eenvoudiger maakt om in de toekomst eventueel naar een ander framework te migreren.

Python

Voor de eerste experimenten koos ik voor de bekende weg. Ik ben erg comfortabel met programmeren in Python, en heb ook de nodige data science tooltjes gemaakt met Python in combinatie met Flask en FastAPI. Beide zijn simpele frameworks voor webdevelopment, waarmee je met Jinja-templates snel een werkende website kunt maken.

De vergelijking tussen Flask en FastAPI kan beter in een afzonderlijke post worden beschreven. Voor een simpele blog zijn ze beiden prima geschikt. Voor de eerste experimenten voor deze blog heb ik weer voor FastAPI gekozen, maar vooral omdat ik in de laatste projecten FastAPI heb gebruikt. Ook ben ik wel gecharmeerd van de ingebouwde geautomatiseerde Swagger documentatie.

Het idee was om relatief snel iets in elkaar tikken. De basis opzetten was ook zo gebeurd. Maar al snel werden dingen als navigatie en asset-management een ding. Hoe krijg ik mijn artikelen zo eenvoudig mogelijk gepubliceerd? Hoe verwerk ik recepten tot doorzoekbare elementen? Dit resulteerde eerste instantie in een receptenparser. Voor de doorzoekbaarheid heb ik een begin gemaakt om het weg te schrijven naar een database. Maar als het dan toch ingewikkeld wordt, vind ik het ook wel leuk om iets anders dan de bekende weg uit te proberen. In plaats van met Python verder te gaan, besloot ik om een begin te gaan maken met Go.

Go en Svelte

Dat ik de backend in Go wilde schrijven was duidelijk, maar zonder frontend heb je natuurlijk geen website. Het frontend-landschap is inmiddels gigantisch, en je kunt jezelf goed verliezen om daar een keuze in te maken.

Veel van die frameworks zijn gebaseerd op JavaScript, een taal waar ik me nog wel wat verder in zou kunnen ontwikkelen. In het verleden heb ik het een en ander met Vue gedaan, maar nog niet genoeg om me er echt comfortabel mee te voelen. De keuze was dus nog vrij. Vue is een heel krachtig framework, waarbij je veel controle hebt over interactie tussen verschillende elementen op je website, maar ik heb het tegelijkertijd ervaren als veel gedoe. Na wat vergelijkingssites te hebben bekeken, kwam ik uit op Svelte. Het is een redelijk nieuw framework met wat minder boilerplate dan Vue en React. Josh Collinsworth beschrijft Svelte op zijn blog bijvoorbeeld als “React without the bullshit” en verkiest het ook boven Vue. In die blogpost vergelijkt hij Svelte met React en Vue.

Ik kwam deze post tegen die uitlegt hoe je een website met Go en Svelte kunt schrijven, en het leek me een leuk experiment om daarmee aan de slag te gaan.

Svelte Sveltekit

Doordat Svelte een relatief nieuw framework is, is de documentatie soms een beetje verwarrend. Ook heb je naast Svelte SvelteKit, wat het nog makkelijker zou moeten maken om webapplicaties met Svelte te maken. Dit zorgt er echter wel voor dat het zo nu en dan wat ingewikkelder is om de juiste oplossing voor je probleem te vinden.

Na de nodige experimenten met het bouwen in Svelte en worstelingen met afbeeldingen automatisch verkleinen, kwam ik tot de conclusie dat deze manier van werken ook eigenlijk wat overdreven is voor mijn doel. Het is helemaal niet de bedoeling om een geavanceerde webapplicatie te maken met gebruikersinteractie veel anders dan dat een gebruiker op een link klikt. Ook is interactie tussen verschillende elementen in de applicatie iets wat niet eens onderaan mijn functionaliteitswensenlijstje staat. Ik wil een omgeving waar ik wat kwijt over eten (bites) en over willekeurige technische dingen (bits).

Hugo: drie keer is scheepsrecht

Tijdens de zoektocht hoe ik bepaalde dingen in Svelte moest implementeren kwam ik op een site waarbij gesteld werd dat iemand het zich wel erg moeilijk maakte door Svelte te gebruiken voor een simpele website. Er werd aangeraden om eens naar Hugo te kijken. Hugo is “The world’s fastest framework for building websites”, geschreven in Go. Het is een statische HTML en CSS website generator, waarbij je Markdown gebruikt als formaat om content in te schrijven. Simpel, snel én Markdown als formaat voor mijn content: het proberen waard.

Doordat Hugo niet afhankelijk is van JavaScript liep ik er meteen al minder tegenaan dat mijn JavaScript-skills nog wel wat verbeterd kunnen worden. Wel heb ik ervoor gekozen om zelf een lay-out template te ontwikkelen, in plaats van een bestaande te gebruiken. Dit maakt het wel veel meer werk, maar de Go template-taal is erg leuk om mee te werken en de frontend vanaf 0 zien uitgroeien geeft erg veel voldoening. Hugo biedt veel structuur in het ontwikkelen van je lay-out, en het is erg eenvoudig om verschillende templates in te zetten voor verschillende typen webpagina’s. Hierdoor is het bijvoorbeeld mogelijk om in de toekomst naast lay-outs voor bits en bites ook een lay-out voor bijvoorbeeld reviews van boeken toe te voegen. Dit geeft erg veel flexibiliteit.

Front matter

Een extra voordeel van Hugo is dat je je content kunt structureren door het gebruik van Front Matter. In Front Matter kun je zelf-gedefinieerde metadata kwijt. Deze metadata kun je vervolgens weer tonen in de frontend, zoals een titel, datum en samenvatting van een pagina.

Ook is het hierdoor mogelijk de metadata te gebruiken om bijvoorbeeld te sorteren en filteren, zonder dat de data geïndexeerd hoeft te worden in een database. Zo neem ik de ingrediënten van recepten op in Front Matter, waardoor die (in de toekomst) weer goed te verwerken zijn in filters.

Afbeeldingen verkleinen

Een van mijn eisen voor een framework was het eenvoudig invoegen en verkleinen van afbeeldingen. Hugo biedt uitgebreide opties voor image processing. Voor afbeeldingen in Markdown zijn er twee opties om deze automatisch te laten verwerken: via Markdown Render Hooks of Shortcodes. In het eerste geval worden bij het converteren van Markdown naar HTML afbeeldingen automatisch verwerkt via de html-template die je specificeert in de render-image Markdown Hook. In het geval van Shortcodes maak je html-template die je middels een shortcode in Markdown op kunt nemen. Omdat ik zo min mogelijk wil afwijken van Markdown, heb ik gekozen voor een Markdown Render Hook.

Keep it stupid simple

Het is heel verleidelijk om allemaal toffe features te bedenken die uiteindelijk niet noodzakelijk zijn voor het functioneren van je site. Zo wilde ik graag tijdens het schrijven op willekeurige plekken tags kunnen toevoegen. Daarmee maakte ik het eigenlijk onnodig moeilijk. Met aanpak waarbij ik metadata en content gescheiden hield had ik waarschijnlijk een bestaande Markdown-parser kunnen gebruiken. Aan de andere kant zou ik dan nog steeds over de pijplijn moeten nadenken.

Vaak is het ook gewoon een kwestie van: kies iets en ga ermee aan de slag. Ik ben heel goed in verschillende opties uitzoeken en analyseren wat het beste zou kunnen passen in verschillende voor-het-geval-dat scenario’s. En dan zowel voor de front- als voor de backend een framework kiezen waar je niet bekend mee bent is misschien wat ambitieus. Gelukkig komt al het goede in drieën, en bouw ik inmiddels met veel plezier in Hugo.