Ik kies ervoor om mijn volgende (deze) site zelf te bouwen op basis van Gatsby en JavaScript. Maar welk platform je ook kiest: je hebt goede techneuten nodig.
Mijn artikel over waarom ik stop met WordPress maakte nogal wat los. Waarbij ik moet opmerken dat de toon van de conversatie uiterst beschaafd, genuanceerd en redelijk was. Dat is wel eens anders online en het pleit wat mij betreft enorm voor de sfeer in de Nederlandse webbouwers-community. Voordat ik begin wil ik de vruchtbare discussie dus even eren met een korte samenvatting. Daarna vertel ik je over de opzet van mijn nieuwe site.
Even voor de duidelijkheid: ik beweer natuurlijk niet de wijsheid in pacht te hebben. Ik adviseer meeste van mijn klanten ook helemaal niet om van WordPress af te stappen. Ik druk ze wél op het hart om een goede developer naar performance en veiligheid van hun site te laten kijken.
Want daar is iedereen het wel over eens: een systeem is zo goed als degene die het optuigt en onderhoudt. Je kunt snelle, veilige WordPress-sites bouwen die ook nog fijn zijn om aan te werken. Maar je kunt er ook met een paar klikken een onwerkbare draak van maken. Dat gebeurt dan ook heel erg vaak. De fout die we hebben gemaakt met WordPress, is om ons te laten wijsmaken dat iedereen er een site mee kan bouwen. Ja, de installatie is zo gepiept. En ja, voor alles is een plugin. En ja, je kunt op ThemeForest zo een vormgevinkje aanschaffen. Maar dan heb je nog geen goede site. Ik heb me daar natuurlijk ook schuldig aan gemaakt, toen ik sites begon te maken voor klanten. Die waren in het begin echt niet geweldig. Gelukkig heb ik de meeste van die sites kunnen overdragen aan technisch beheerders, die er waarschijnlijk (hopelijk) behoorlijk wat opruimwerk in hebben verricht…
Zoek een goede developer
Bottom line: voor een goede site heb je een goede developer nodig. Welke technologie je ook kiest. Heb je die niet in huis? Dan is het misschien beter om voor een SaaS-oplossing te gaan. Zo zag ik in de discussie een fan van Blogger, het blogplatform van Google. Een goede developer kan blijkbaar ook zo’n beetje alles met WordPress. Mensen vertelden me de afgelopen dagen dat ze WordPress als headless CMS gebruiken en zo inzetten voor omnichannel content. WordPress is dus nog lang niet uitgespeeld. Drupal, ook een CMS dat draait op de LAMP-stack, zet ook belangrijke stappen in die richting. Bas van der Lans, vooraanstaand WordPress-bouwer, liet me weten dat hij aan een artikel werkt waarin hij uitlegt waarom WordPress juist de enige weg voorwaarts is de komende jaren. Lees dat dus eerst even voordat je je site in de prullenbak gooit… Tegelijkertijd zijn er ook al heel veel mensen bezig met andere manieren om sites te maken, waarbij static sites en JAMStack de belangrijkste innovaties zijn. Dat is, niet toevallig, ook de technologie waar ik uiteindelijk op uitgekomen ben. Daarover zo meteen meer.
Kritisch blijven
Raad ik dus iedereen aan om morgenochtend de stekker uit zijn WordPress-site te trekken? Zeker niet. Kun je met strak management een goed draaiende WordPress-site in de lucht houden, al dan niet met webwinkel en 65 custom post types? Absoluut. Zijn er developers die met WordPress 100 scoren op Google PageSpeed Insights? You betcha. Beslissingen over IT en contentmanagement zijn altijd strategische beslissingen. Die verschillen dus per bedrijf, per toepassing en per situatie. Er is geen one size fits all. Maar je bent al een heel eind als je de alternatieven hebt bekeken en aan jezelf kunt uitleggen waarom je voorlopig het beste af bent met WordPress. Voldoet je site op dit moment aan je behoeften? Prima. Geen actie nodig. Maar draai je alles op WordPress, omdat ‘dat nou eenmaal is wat we hebben’ en negeer je daarbij klachten over sitesnelheid, problemen met beheer en problemen bij de overstap naar omnichannel content? Dan is het tijd om eens kritisch naar je keuzes te gaan kijken.
Ik houd gewoon van code
Zo’n discussie maakt altijd dat ik toch ook weer kritisch naar mijn eigen standpunt ga kijken. En toen ik dat deed, zag ik dat er een punt was dat ik niet duidelijk onder woorden had gebracht. Ik had het over de snelheid van de ontwikkelomgeving en mijn aversie tegen WYSIWYG (what you see is what you get)-editors. Wat ik er niet bij vertelde, is dat ik mijn eigen artikelen al jaren in Markdown schrijf, een manier om met pseudo-code teksten te structureren en van metadata te voorzien. Verder ben ik mijn carrière begonnen als software developer. Ik voel me dus thuis in een code-omgeving. Ik bouw mijn site (inclusief de content) nu in Visual Studio, in plaats van in een web-interface. Voor mij voelt dat veel natuurlijker, naadlozer en, ja, sneller dan buttons en tekstvakken. De meeste marketeers, schrijvers en contentmanagers denken daar anders over. Je moet dus aan alle argumenten over ‘wel/niet WordPress en zo niet, wat dan wel’ toevoegen dat een CMS en een technology stack ook moeten passen en bij het soort mensen dat ermee werkt.
And the winner is…
En de winnaar is: GatsbyJS. Wat is GatsbyJS? GatsbyJS is een static site generator, gebaseerd op React. React is, even heel erg grof gesteld (React-developers, don’t shoot me), een dialect van JavaScript (de belangrijkste programmeertaal voor het web) dat zorgt dat je met weinig inspanning data uit verschillende bronnen aan een webpagina of app kunt koppelen. Dat is ideaal als je, vanuit een informatie-architectuur, een site content-first wilt opzetten.
Een ander voordeel van Gatsby is dat het een statische HTML-site maakt van je code en je content. In de site die online staat, zit dus nauwelijks programmacode en zeker geen database. Dat zorgt (of: kan zorgen, want de goeroes vertellen me dat je dit ook kunt verprutsen) voor meer snelheid en meer veiligheid.
Dat gaat allemaal niet zonder slag of stoot, want er is behoorlijk wat technische kennis nodig om een site te maken in Gatsby. Ik ben een aantal maanden bezig geweest om die kennis op te doen, voordat ik aan de bouw van een prototype begon. En nog zijn er dingen die ik niet voor elkaar krijg. Maar goed, ik houd nou eenmaal van een uitdaging.
Wat is een headless CMS?
Gatsby en de meeste andere static site generators zijn gebouwd om hun content uit zogenaamde headless CMS’en te halen. Maar wat zijn dat voor dingen? Bijna alle klassieke CMS’en zijn gebouwd om pagina’s te produceren en niet om informatie te beheren. Dat maakt het moeilijk om content in te zetten op andere kanalen dan je website. Dit is natuurlijk ook doorgedrongen tot de CMS-wereld. Dus ontstaan er steeds meer systemen die content beheren in een flexibel te definiëren datastructuur, los van presentatie en dus zonder ‘gezicht’ (vandaar ‘headless’). De content kan dan uit de database gehaald worden en gebruikt op websites, in apps, voor e-mail, etc. Omdat je in de meeste gevallen sowieso een website zult willen hebben waar je al je content verzamelt, zijn er ook veel hybride systemen die weliswaar een website kunnen genereren, maar je content ook aan andere applicaties kunnen aanbieden. Dit geeft je een uitstekende basis voor omnichannel content.
Headless contentmanagement ligt aan de basis van de stack die ik uiteindelijk heb gekozen voor mijn nieuwe site: de JAMStack. JAMStack is niet zozeer een technologie-stack, maar een concept. De J staat voor Javascript, de populairste programmeertaal van het web. De A staat voor ‘API’, of Application Programming Interface. Dit is de manier waarop webapplicaties met elkaar praten. JAMStack-websites halen hun content op via deze API’s. De content kan dus overal vandaan komen: uit een (headless) CMS, maar ook uit Google Docs of uit externe databases zoals die van het CBS, het KNMI of Bol.com (om maar wat dwarsstraten te noemen). Tenslotte staat de M voor ‘markup’. Dat is de uiteindelijke vormgeving van je content, die dus compleet losstaat van de content zelf.
Hoe je de JAMStack technisch invult, is compleet aan de ontwikkelaar. Ik heb dus besloten mijn nieuwe site te bouwen als statische site. Via een handig, automatisch proces (onder softwarenerds bekend als ‘continuous delivery’) ‘weet’ mijn webhost dat mijn site of content veranderd zijn en bouwt automatisch een nieuwe versie van de site. Dat levert je een razendsnelle, nauwelijks te hacken site op die het altijd doet, terwijl je ook op ieder gewenst moment content kunt aanpassen en toevoegen. Best of both worlds, wat mij betreft. De content sla ik gewoon, heel ouderwets, op in tekstbestanden. Omdat ik dat lekker vind werken.
Die content maakt dus in principe deel uit van de code en ik gebruik daarbij het versiebeheersysteem waar de code in zit (GitHub) als CMS. Wat mij betreft een verademing, want versiebeheer is in de meeste CMS’en een ondergeschoven kindje. Mijn nieuwe host, Netlify, biedt een editor aan (ze noemen het met enige overdrijving ‘Netlify CMS’), waarmee je die bestanden ook in een wat meer WordPress-achtige omgeving, en zonder toegang tot een volledige ontwikkelomgeving, kunt bewerken. Dit werkt voor mij als eenpitter allemaal perfect, maar je kunt het natuurlijk niet uitrollen in een marketingorganisatie. Daarvoor moet je gaan kijken naar een echt headless CMS. Bij eerdere experimenten heb ik zitten spelen met Contentful, wat er veelbelovend uitziet.
'Perfect' is the enemy of 'progress'
Is dat nieuwe ding dat ik ga maken dan perfect? Niet bepaald. Menustructuren zijn hard-coded, een deel van de content is nog steeds georganiseerd in pagina’s, een heleboel functionaliteit die de WordPress-site wel had is ineens verdwenen… De meeste van deze imperfecties komen voort uit mijn gebrekkige programmeerskills, in combinatie met mijn verlangen om het allemaal snel live te krijgen. Ik neem ze dus even voor lief. Want ik wil vooruit.
Het principe van innovatie, van creative destruction is dat we dingen wegdoen om ze te vervangen door andere dingen. In de verwachting dat het er beter van wordt, maar zonder dat we precies weten waar we gaan belanden. Dat betekent dat we ook af en toe nostalgisch zullen terugverlangen naar de dingen de ooit waren en onszelf vervloeken dat we ze ooit hebben opgegeven. So be it. Ik neem afscheid van WordPress en verken nieuwe wegen.
