Wat zijn webontwikkelingsbibliotheken?

Een webontwikkelingsbibliotheek is een verzameling kant-en-klare code die je in je eigen project gebruikt. Iemand anders heeft een probleem opgelost en jij hoeft dat niet opnieuw te doen.

Datums opmaken, grafieken tekenen, formulieren controleren, betalingen afhandelen: voor vrijwel elk terugkerend probleem bestaat er iets. Je haalt het binnen, roept het aan en gaat verder met het deel dat wel uniek is aan jouw site.

Wat een bibliotheek eigenlijk is

Elke programmeertaal heeft een eigen ingebouwde verzameling functies. In PHP zitten er honderden voor tekst, datums en bestanden zonder dat je iets installeert, en in JavaScript geldt hetzelfde. Wat mensen bedoelen met een bibliotheek is het deel dat daar niet in zit en dat je er zelf bij haalt.

De meeste van die bibliotheken zijn open source. Je mag ze gratis gebruiken, de broncode inzien en aanpassen. Dat is de reden dat het web zo snel gebouwd kan worden en tegelijk de reden dat vrijwel elke website onderdelen bevat die de bouwer nooit heeft gelezen.

Voor een ondernemer is dat laatste het punt dat telt. Op je site draait code van tientallen onbekende mensen. Dat is normaal, en het betekent wel dat iemand moet bijhouden of die code nog deugt.

Het verschil met een framework

Dit onderscheid klinkt academisch en is in de praktijk het meest bruikbare wat er over dit onderwerp te zeggen valt.

Bij een bibliotheek houd jij de regie. Je roept hem aan wanneer je hem nodig hebt en je bepaalt zelf hoe je project is opgebouwd. Een bibliotheek voor grafieken schrijft je niet voor hoe de rest van je site in elkaar zit.

Bij een framework houdt het framework de regie. Het bepaalt de mappenstructuur, de opstartvolgorde en de manier waarop onderdelen elkaar aanroepen. Jij vult in wat het van je vraagt.

Het praktische verschil is de uitgang. Uit een bibliotheek stap je meestal in een middag: je vervangt hem door een andere of je schrijft dat ene stukje zelf. Uit een framework stap je niet, want je hele project is eromheen gebouwd. Als je één afweging onthoudt bij het kiezen, dan deze.

Hoe een bibliotheek in je project terechtkomt

Er zijn drie routes, en ze verschillen in hoeveel je er later aan kwijt bent.

De oudste is een regel in je HTML die naar een bestand verwijst. Snel geregeld, en je hebt geen enkel overzicht van wat er binnenkomt zodra je dat vijftien keer hebt gedaan.

De tweede is een pakketbeheerder: npm voor JavaScript, dat sinds 2010 bij Node.js hoort, en Composer voor PHP, dat sinds 2012 bestaat. Je noteert in één bestand welke pakketten je wilt, en het gereedschap haalt ze op inclusief de pakketten die zij op hun beurt nodig hebben.

De derde route is dat het pakket al klaarstaat. WordPress levert een set bibliotheken mee die elke plugin mag gebruiken, zodat niet iedere plugin zijn eigen kopie meebrengt.

Versienummers en het slotbestand

Bibliotheken hebben een nummer met drie delen, bijvoorbeeld 4.17.21. Die volgorde is een afspraak die semantische versionering heet.

Het eerste getal gaat omhoog als er iets breekt aan de manier waarop je de bibliotheek aanroept. Het tweede als er functies bij komen die niets stukmaken. Het derde bij een reparatie. Zie je een sprong in het eerste getal, dan kost bijwerken werk.

In je projectbestand staat vaak geen exact nummer maar een bandbreedte, zoals "alles vanaf 4.17 tot 5". Dat is prettig voor beveiligingsreparaties en het betekent dat twee collega's op verschillende dagen een andere versie binnenhalen. Daarvoor bestaat het slotbestand: package-lock.json bij npm, composer.lock bij Composer. Daarin staat welke versie er precies is opgehaald.

Zet dat slotbestand altijd mee in je versiebeheer. Zonder dat bestand is het antwoord op de vraag "wat draaide er vorige week toen het nog werkte" niet meer te geven.

De grote namen naast elkaar

Er zijn een paar namen die je overal tegenkomt. Ze doen niet hetzelfde, en dat is precies wat in de vergelijkingen op internet ontbreekt.

React

Ontstaan bij Facebook en sinds 2013 openbaar. Strikt genomen een bibliotheek: het regelt alleen hoe je scherm eruitziet bij een bepaalde toestand, en al het andere kies je erbij. Daardoor is het populair en tegelijk verwarrend voor beginners, want twee React-projecten kunnen totaal anders zijn opgezet. Meer erover staat in het artikel over ReactJS.

Vue

Begonnen in 2014 door Evan You, die eerder bij Google aan Angular werkte. Vue zit tussen de andere twee in: je kunt hem op één pagina losjes gebruiken en je kunt er een compleet project op bouwen. Vue 2 kreeg eind 2023 geen ondersteuning meer, wat voor bestaande projecten een verbouwing betekende. Zie het artikel over Vue.js.

Angular

Van Google, en het duidelijkste voorbeeld van een framework. Het schrijft je opzet voor en levert vrijwel alles mee. AngularJS uit 2010 en Angular vanaf 2016 zijn twee verschillende producten met een vergelijkbare naam; de overstap was een herbouw en niet een update. AngularJS kreeg op 31 december 2021 geen ondersteuning meer. Zie het artikel over AngularJS.

Node.js

Hoort in dit rijtje thuis en is iets anders dan de rest. Node is geen bibliotheek maar een omgeving waarin JavaScript buiten de browser draait, op de server, en dat sinds 2009. Daardoor kun je dezelfde taal aan beide kanten gebruiken. Zie het artikel over Node.js.

En de rest

Svelte doet het werk tijdens het bouwen in plaats van in de browser, wat kleinere bestanden oplevert. Alpine.js is bedoeld voor een beetje gedrag op een verder gewone pagina, en Chart.js tekent grafieken.

Mijn eigen maatstaf: heb je een site met pagina's, dan heb je hier niets van nodig. Heb je een scherm waarin veel dingen tegelijk op elkaar reageren, zoals een planning, een configurator of een dashboard, dan wordt het interessant.

Wat er aan de achterkant gebeurt

De discussie gaat meestal over de voorkant, terwijl er aan de serverkant net zo goed bibliotheken draaien.

In PHP zijn Laravel en Symfony de bekendste frameworks. Daarnaast bestaat er een grote voorraad losse pakketten voor dingen die je niet zelf wilt bouwen: PDF's maken, e-mail versturen, betalingen afhandelen. Die haal je met Composer binnen en ze zijn samen goed voor het grootste deel van de code in een gemiddeld project.

Bij Node is Express de bekendste, bij Python Django en Flask, en Ruby on Rails is het schoolvoorbeeld van een framework dat je veel keuzes uit handen neemt. Hoe deze kant werkt staat in het artikel over back-end ontwikkeling.

Het verschil met de voorkant is dat een bibliotheek op de server je bezoeker niets kost aan laadtijd. Hij kost je wel onderhoud en hij kan een beveiligingslek bevatten dat direct bij je gegevens komt.

Bibliotheken voor de vormgeving

Bootstrap kwam in 2011 van Twitter en was jarenlang de standaardmanier om snel iets neer te zetten dat op alle schermen werkte. Tailwind, van 2017, pakt het anders aan: je zet de opmaak met korte klassen direct in je HTML.

Beide leveren je snelheid op en beide slepen iets mee. Bij Bootstrap krijg je opmaak voor onderdelen die je nooit gebruikt. Bij Tailwind hoort een bouwstap die de ongebruikte regels eruit haalt, en die moet dan wel goed staan.

Het herkenbare nadeel is dat sites er hetzelfde uit gaan zien. Je ziet aan een pagina welke set eronder ligt. Voor een bedrijf dat zich juist wil onderscheiden is dat een reden om de opmaak zelf te schrijven of in elk geval ver van de standaardinstellingen af te blijven.

Wat de browser tegenwoordig zelf kan

Hier zit de kennis die de meeste bibliotheken overbodig maakt, en juist die is het minst bekend.

De reden dat er in 2006 bibliotheken als jQuery ontstonden, was dat browsers onderling erg verschilden. Hetzelfde stukje code werkte in de ene browser wel en in de andere niet. Dat probleem is grotendeels weg.

Elementen opzoeken, gegevens ophalen bij de server, klassen aan- en uitzetten: dat kan de browser al jaren zelf, in één regel. Een dialoogvenster zit sinds 2022 ingebouwd in het dialog-element. Uitklapbare blokken maak je met details en summary zonder één regel JavaScript. De :has()-selector, waarmee je een element opmaakt op basis van wat erin zit, werkt sinds eind 2023 overal.

De nuttigste vraag voordat je iets installeert is dus of de browser dit inmiddels zelf kan. Vaak is het antwoord ja, en scheelt het je tachtig kilobyte en jaren onderhoud.

Hoe je er een kiest

• Heb je hem echt nodig? Een bibliotheek voor één animatie is dat zelden waard. Kijk eerst of het zonder kan.
• Wordt hij onderhouden? Kijk naar de datum van de laatste uitgave, naar het aantal openstaande meldingen en of daar nog antwoord op komt. Eén beheerder die er alleen voor staat is een risico.
• Hoe groot is hij? Elke kilobyte komt bij je laadtijd. Kijk of je alleen het deel kunt laden dat je gebruikt.
• Hoeveel sleept hij mee? Een pakket dat zelf twintig andere pakketten nodig heeft, geeft je twintig extra dingen die kunnen breken.
• Wat is de licentie? Daar zit meer aan vast dan de meeste mensen denken.

Licenties en wat ze van je vragen

Gratis te downloaden is niet hetzelfde als vrij te gebruiken zoals jij wilt. Bij elke bibliotheek hoort een licentie, en die is juridisch bindend.

MIT en BSD zijn de ruimste: je mag alles, zolang de oorspronkelijke vermelding in je code blijft staan. Apache 2.0 lijkt daarop en regelt daarnaast octrooien.

De GPL is anders. Die verplicht je om je eigen code onder dezelfde voorwaarden vrij te geven als je die met de bibliotheek combineert en vervolgens verspreidt. Voor een website die je alleen zelf draait speelt dat nauwelijks, voor een plugin die je verkoopt wel.

WordPress zelf staat onder de GPL, versie 2 of later. Plugins en thema's die je verspreidt hebben daarom een licentie nodig die daarmee samengaat. Let op dat Apache 2.0 wel samengaat met GPL versie 3 en niet met versie 2. Daar loopt een bureau tegenaan zodra een klant vraagt of hij de code mag meenemen.

Wat het met je laadtijd doet

Elke bibliotheek die de browser moet ophalen, uitpakken en uitvoeren kost tijd. Bij JavaScript is de uitvoertijd vaak schadelijker dan de downloadtijd, zeker op een telefoon van een paar jaar oud.

Sinds 12 maart 2024 meet Google de reactiesnelheid van een pagina met INP, wat staat voor Interaction to Next Paint. Dat cijfer kijkt hoe lang het duurt voordat er iets gebeurt nadat iemand klikt of tikt. Zwaar JavaScript is daar de belangrijkste oorzaak van, want de browser kan maar één ding tegelijk.

Laad daarom alleen de onderdelen die je gebruikt, splits je code op zodat elke pagina alleen zijn eigen deel binnenhaalt, en zet scripts die niet meteen nodig zijn achteraan. Bij een gewone bedrijfssite zit de grootste winst meestal in iets weghalen.

Aanvallen via de toeleveringsketen

Dit risico zien mensen het minst aankomen. Je vertrouwt de bibliotheek die je zelf koos, en daarmee ook alle pakketten die hij meebrengt en iedereen die daaraan mag schrijven.

In maart 2016 haalde een ontwikkelaar zijn pakketten uit npm weg na een naamconflict. Eén ervan bestond uit een handjevol regels code en werd door duizenden projecten gebruikt. Wereldwijd liepen bouwprocessen vast.

In november 2018 droeg de beheerder van event-stream het onderhoud over aan een vrijwilliger die zich aanbood. Die voegde code toe die bitcoinsleutels stal. In maart 2024 bleek er een achterdeur te zitten in xz, een compressiepakket dat op vrijwel elke Linux-server staat, geplaatst door iemand die twee jaar lang meehielp om vertrouwen op te bouwen.

Het voorbeeld dat het dichtst bij een gewone website ligt is polyfill.io. Die dienst leverde reparatiecode voor oude browsers en stond in miljoenen pagina's als externe verwijzing. Het adres kwam begin 2024 in andere handen en stuurde in juni 2024 bezoekers door naar kwaadaardige pagina's. Die sitehouders hadden jaren eerder één regel in hun HTML gezet en verder niets gedaan.

Bijhouden zonder dat het een project wordt

Aan de meeste lekken hoef je zelf niets te bedenken. Er bestaan openbare registers van bekende kwetsbaarheden, en je gereedschap kan daar zelf in kijken.

Bij npm doe je dat met npm audit, bij Composer zit er sinds 2022 een vergelijkbare controle in. Op GitHub waarschuwt Dependabot je automatisch en maakt het desgewenst zelf een voorstel om bij te werken. Bij WordPress zie je meldingen over onveilige plugins in je beheerscherm.

Waaraan merk je dat het misgaat? Meestal niet aan een foutmelding. Een site die is misbruikt via een verouderde bibliotheek werkt gewoon, en ondertussen staan er verborgen links in je pagina's, worden bezoekers vanaf een telefoon doorgestuurd, of duikt je domein op in de waarschuwingslijst van Google. Wat je daaraan doet staat in het artikel over WordPress beveiligen.

Praktisch ritme voor een kleine site: maandelijks bijwerken, altijd eerst een back-up, en daarna even door de site klikken op de plekken waar een bezoeker iets moet kunnen. Dat is genoeg.

Bibliotheken die van een andere server komen

Je kunt een bibliotheek vanaf je eigen hosting laden of vanaf een openbaar verdeelnetwerk. Dat tweede was jarenlang het advies, omdat bezoekers het bestand dan al in hun browser hadden staan van een andere site.

Dat voordeel is weg. Browsers houden hun tijdelijke opslag sinds enkele jaren per website apart, juist om te voorkomen dat sites elkaars bezoekers kunnen volgen. Wat overblijft zijn de nadelen: een extra partij die kan uitvallen, een extra verbinding die tijd kost, en het IP-adres van je bezoeker dat naar een ander bedrijf gaat. Dat laatste vraagt een grondslag onder de AVG.

Zet die bestanden dus op je eigen server. Moet het toch extern, gebruik dan het integrity-kenmerk in je scripttag. Daarmee legt de browser de vingerafdruk van het verwachte bestand vast en weigert hij het te draaien als er iets aan gewijzigd is. Bij polyfill.io had dat de schade voorkomen.

In WordPress heten ze plugins

Voor de meeste ondernemers is dit de vorm waarin ze met bibliotheken te maken hebben. Een plugin is code van iemand anders die op jouw site draait, met dezelfde rechten als de rest van je site.

WordPress levert er zelf een aantal mee die plugins mogen gebruiken: jQuery, Underscore, Backbone en Lodash. Sinds WordPress 5.0 van december 2018 draait de blokeditor op React, wat betekent dat die bibliotheek in vrijwel elke WordPress-site zit zonder dat iemand hem heeft gekozen.

Waar je op let is hetzelfde rijtje als hierboven: wanneer is hij voor het laatst bijgewerkt, hoeveel installaties heeft hij, en werkt hij met jouw versie van WordPress. Verwijder wat je niet gebruikt, want uitgeschakeld is niet weg: de bestanden staan er nog en een lek erin is nog steeds te misbruiken.

Let ook op stapeling. Vijf plugins die elk hun eigen schuifbalk meebrengen, geven je vijf schuifbalken in je paginabron. Dat zie je terug in je laadtijd en in het aantal dingen dat kan breken bij een update.

De vraag die ik stel voordat er iets bij komt: wat gebeurt er als dit over drie jaar niet meer wordt onderhouden. Valt er dan een deel van de site stil, dan is het een zwaardere beslissing dan hij lijkt. De site die het langst meegaat is meestal de site met de minste onderdelen.

Veelgestelde vragen over webontwikkelingsbibliotheken

Wat is een webontwikkelingsbibliotheek?

Een verzameling kant-en-klare code die iemand anders heeft geschreven en die jij in je eigen project kunt gebruiken. Je haalt hem binnen en roept de functies aan die je nodig hebt.

De meeste zijn open source en gratis. Je betaalt in onderhoud: elke bibliotheek moet je bijhouden zolang je site bestaat.

Wat is het verschil tussen een bibliotheek en een framework?

Bij een bibliotheek roep jij de code aan; bij een framework roept de code jou aan. Een framework bepaalt de opzet van je hele project en jij vult de gaten in.

Het verschil dat je merkt is de uitgang. Een bibliotheek vervang je in een middag, een framework niet zonder je project opnieuw te bouwen.

Welke bibliotheek moet ik kiezen voor mijn website?

Voor een gewone bedrijfssite met pagina's, een contactformulier en misschien een agenda: geen. WordPress met een goed thema doet dat werk al, en alles wat je erbij zet is onderhoud dat je niet terugverdient.

Bouw je een toepassing waarin veel op één scherm tegelijk gebeurt, dan is React of Vue een verdedigbare keuze. Kies dan wat je ontwikkelaar echt kent, want die kennis weegt zwaarder dan het verschil tussen de twee.

Heb ik jQuery nog nodig?

Voor nieuw werk niet. Alles waarvoor jQuery in 2006 werd gemaakt kunnen browsers nu zelf, meestal in evenveel regels.

Verwijderen uit een bestaande WordPress-site is een ander verhaal. Plugins en thema's leunen er nog volop op, dus jQuery weghalen breekt vaak meer dan het oplevert.

Zijn webontwikkelingsbibliotheken gratis?

De bekende zijn gratis te gebruiken, ook commercieel. Sommige hebben een betaalde variant met extra onderdelen of met ondersteuning, en een enkele vraagt een licentie zodra je er geld mee verdient.

Kijk altijd in het licentiebestand voordat je iets in een klantproject zet. MIT, BSD en Apache 2.0 zijn ruim, de GPL stelt voorwaarden aan wat je verspreidt.

Wat is npm en wat is Composer?

npm is de pakketbeheerder van Node.js en tegelijk het register waar de meeste JavaScript-bibliotheken staan. Composer is de tegenhanger voor PHP. Met één opdracht haal je een pakket binnen, inclusief alles wat dat pakket zelf nodig heeft.

Ze doen hetzelfde werk voor een andere taal en zijn niet uitwisselbaar. In een WordPress-project kom je ze allebei tegen zodra er maatwerk in zit.

Hoe leer ik met een bibliotheek werken?

Begin bij de officiële documentatie van de bibliotheek zelf en bouw meteen iets kleins waar je het in gebruikt. Losse cursussen en video's zijn nuttig als aanvulling, en zonder eigen project blijft het hangen.

Kies er één en blijf daar een tijdje bij. De meeste mensen die vastlopen, zijn aan drie bibliotheken tegelijk begonnen omdat ze overal iets anders lazen.

Maakt een bibliotheek mijn website langzamer?

Ja, in de meeste gevallen. Er komt een bestand bij dat opgehaald, ingelezen en uitgevoerd moet worden, en dat laatste kost op een telefoon het meeste tijd.

Hoe erg het is hangt af van de grootte en van wat hij doet. Een bibliotheek die pas laadt als iemand op een knop drukt, kost je bezoeker niets bij het openen van de pagina.

Hoe vaak moet ik bibliotheken bijwerken?

Beveiligingsreparaties zo snel mogelijk, de rest op een vast moment, bijvoorbeeld maandelijks. Wachten tot je een jaar achterloopt maakt het bijwerken tot een verbouwing.

Maak eerst een back-up die je zelf kunt terugzetten. Werk daarna bij en klik de site door op de plekken waar iets moet gebeuren: je formulier, je zoekveld, je afspraakknop. Die breken zonder dat er een foutmelding verschijnt.

Wat is een aanval via de toeleveringsketen?

Een aanval waarbij iemand niet jouw site binnendringt, maar een pakket dat jij gebruikt. Zodra jij bijwerkt, komt de kwaadaardige code vanzelf op je server terecht.

Dat gebeurt door een account van een beheerder over te nemen of door het onderhoud van een populair pakket vriendelijk over te nemen. Het is de reden om te weten wat je gebruikt en om niet blind alles bij te werken op een productieomgeving.

Kan ik een bibliotheek beter zelf hosten of van een CDN laden?

Zelf hosten, in vrijwel alle gevallen. Het oude voordeel van een gedeeld bestand is verdwenen doordat browsers hun opslag per website scheiden.

Laad je toch extern, zet dan het integrity-kenmerk in je scripttag, zodat de browser weigert een gewijzigd bestand uit te voeren.

Welke bibliotheken zitten standaard in WordPress?

Onder meer jQuery, Underscore, Backbone en Lodash, plus React voor de blokeditor sinds versie 5.0 uit december 2018. Plugins horen die gedeelde versies te gebruiken in plaats van hun eigen kopie mee te brengen.

Een plugin die dat niet doet, laadt dezelfde code een tweede keer. Dat kost snelheid en veroorzaakt soms conflicten die zich uiten in knoppen die niet reageren.

Moet ik als ondernemer weten welke bibliotheken mijn site gebruikt?

Je hoeft de namen niet te kennen, wel wie ze bijhoudt en wat er gebeurt als er een lek in zit.

Vraag je bouwer om één afspraak op papier: hoe vaak wordt er bijgewerkt, wie controleert of de site daarna nog werkt, en waar staan de back-ups. Dat is het hele beheer van dit onderwerp voor een klein bedrijf.