11 okt 2025·8 min
Rasmus Lerdorf en PHP: Van persoonlijk hulpmiddel tot webstandaard
Het verhaal van Rasmus Lerdorf en PHP—hoe een kleine set webscripts uitgroeide tot een veelgebruikt platform, en waarom PHP nog steeds veel sites aandrijft.
Het verhaal van Rasmus Lerdorf en PHP—hoe een kleine set webscripts uitgroeide tot een veelgebruikt platform, en waarom PHP nog steeds veel sites aandrijft.
PHP begon niet als een groot platform of als een zorgvuldig ontworpen taal. Het ontstond omdat Rasmus Lerdorf een concreet probleem wilde oplossen: zijn persoonlijke website onderhouden zonder steeds hetzelfde handwerk te doen.
Dat detail is belangrijk omdat het veel verklaart over waarom PHP aanvoelt zoals het doet—zelfs vandaag.
Lerdorf was een ontwikkelaar voor het vroege web, toen pagina's meestal statisch waren en alles buiten simpele HTML snel tamelijk omslachtig werd om bij te werken. Hij wilde eenvoudige scripts die bezoekers konden bijhouden, gedeelde paginagedeelten hergebruiken en dynamische inhoud konden genereren.
Met andere woorden: hij wilde hulpmiddelen die hem hielpen sneller wijzigingen uit te rollen.
“Persoonlijke hulpmiddelen” was geen merknaam—het was een denkwijze. Vroege webbouwers schreven vaak kleine hulpprogramma's om de saaie delen te automatiseren:
De vroegste versies van PHP werden gevormd door die praktische, gewoon-doen aanpak.
Als je de wortels van PHP kent, vallen veel eigenschappen op hun plek: de focus op het inbedden van code direct in HTML, de uitgebreide standaardbibliotheek gericht op veelvoorkomende webtaken, en de voorkeur voor gebruiksgemak boven academische zuiverheid.
Die keuzes hielpen PHP snel te verspreiden, maar ze brachten ook compromissen met zich mee die we later bespreken.
Dit artikel loopt door hoe PHP groeide van Lerdorf’s scripts naar een community-gedreven taal, waarom het goed paste bij hosting en de LAMP-stack, hoe ecosystemen zoals WordPress het versterkten, en wat modern PHP (7 en 8+) veranderd heeft—zodat je PHP vandaag kunt beoordelen op feiten, niet op nostalgie of hype.
Het web halverwege de jaren 90 bestond grotendeels uit statische HTML. Als je iets dynamisch wilde—een formulier verwerken, een teller tonen, een pagina per bezoeker personaliseren—greep je meestal naar CGI-scripts, vaak geschreven in Perl.
Dat werkte, maar het was niet soepel.
CGI-programma's draaiden als aparte processen voor elke aanvraag. Voor eenvoudige taken betekende dat veel losse onderdelen: een scriptbestand met nauwkeurige permissies, serverconfiguratie en een denkwijze die niet echt leek op “een webpagina schrijven.” Je was niet zomaar wat logica in HTML aan het mengen; je bouwde een klein programma dat HTML als tekst uitspuugde.
Voor hobbysites en kleine bedrijven waren de gemeenschappelijke behoeften repetitief en praktisch:
De meeste mensen zaten op shared hosting met beperkte CPU, geheugen en weinig controle over serverinstellingen. Het installeren van aangepaste modules of langdurige services was niet realistisch. Wat je wel kon doen, was bestanden uploaden en eenvoudige scripts draaien.
Die beperkingen duwden richting een hulpmiddel dat:
Die kloof—tussen statische pagina's en zware scripting—was het alledaagse webprobleem dat PHP probeerde op te lossen.
Rasmus Lerdorf wilde geen programmeertaal uitvinden. Hij wilde iets veel ordinairders: een betere manier om zijn eigen website te beheren.
Het vroegste werk aan “PHP” begon als een verzameling kleine C-programma's die hij gebruikte om bezoeken aan zijn online cv bij te houden, plus een paar hulpprogramma's om basiszaken van de site te regelen zonder constant handmatig pagina's te bewerken.
Destijds was het niet eenvoudig om te weten wie je site bezocht (en hoe vaak). Lerdorf's scripts hielpen verzoeken te loggen en samen te vatten, waardoor het makkelijker werd verkeerspatronen te begrijpen.
Daarnaast bouwde hij helpers voor veelvoorkomende taken—simpele templating, kleine stukjes dynamische output en formulierverwerking—zodat de site “levend” aanvoelde zonder een volledige op maat gemaakte applicatie te worden.
Zodra je hulpmiddelen hebt voor request-tracking, formulierverwerking en het hergebruiken van paginagedeelten, heb je per ongeluk iets gebouwd dat anderen ook kunnen gebruiken.
Dat is het cruciale moment: de functionaliteit zat niet vast aan één layout of pagina. Het was algemeen genoeg dat andere site-eigenaren zich konden voorstellen de aanpak voor hun eigen projecten te kopiëren.
Omdat het als een gereedschapskist begon, waren de ergonomie en het doel praktisch: doe het veelvoorkomende snel, over‑ontwerp niet en houd de drempel laag.
Die houding—bruikbaarheid eerst, verfijning later—maakte PHP vanaf het begin toegankelijk.
De les is simpel: PHP's wortels waren niet academisch of theoretisch. Ze waren probleemgedreven en gericht op het werkend krijgen van een echte website met zo min mogelijk wrijving.
PHP begon niet als een "taal" zoals we die nu vaak verstaan. De eerste publieke mijlpaal was PHP/FI, wat stond voor "Personal Home Page / Forms Interpreter."
Die naam zegt veel: het probeerde niet alles te zijn. Het was bedoeld om mensen te helpen dynamische pagina's te bouwen en webformulieren te verwerken zonder voor elke taak een volledig programma te hoeven schrijven.
PHP/FI bundelde een paar praktische ideeën die samen vroeg webontwikkeling veel minder pijnlijk maakten:
Het was niet gepolijst, maar het verkortte de hoeveelheid lijmcode die mensen moesten schrijven om een pagina werkend te krijgen.
Vroege websites liepen snel tegen een muur aan: zodra je feedbackformulieren, gastenboeken, aanmeldingen of eenvoudige zoekfuncties wilde, moest je gebruikersinvoer accepteren en iets met die invoer doen.
PHP/FI maakte formulierverwerking een kerngebruiksgeval. In plaats van formulieren als geavanceerde feature te behandelen, omarmde het ze—waardoor het makkelijker werd ingediende waarden te lezen en een antwoordpagina te genereren.
Die focus sloot aan bij wat alledaagse site-eigenaren probeerden te bouwen.
Een van PHP/FI's meest invloedrijke ideeën was de templatingstijl: houd HTML als het hoofddocument, en weef er kleine stukjes serverlogica doorheen.
<!-- HTML-first, with small dynamic pieces -->
<p>Hello, <?php echo $name; ?>!</p>
Voor ontwerpers en knutselaars voelde dit natuurlijk: je kon een pagina bewerken en "net genoeg" dynamiek toevoegen zonder een totaal ander systeem te moeten gebruiken.
PHP/FI was niet elegant en probeerde dat ook niet te zijn. Mensen omarmden het omdat het:
Die "killer features" waren niet flashy—ze waren precies wat het vroege web nodig had.
Rasmus Lerdorf's vroege PHP-scripts waren gebouwd om zijn eigen problemen op te lossen: bezoekers bijhouden, gemeenschappelijke paginagedeelten hergebruiken en herhaling vermijden.
Wat die kleine set utilities tot "PHP" maakte zoals de meeste mensen het kennen, was niet één grote herschrijving—het was een geleidelijke trek van andere ontwikkelaars die dezelfde gemak wilden voor hun eigen sites.
Zodra PHP publiek gedeeld werd, begonnen gebruikers fixes, kleine features en ideeën te sturen. Die feedbacklus was belangrijk: het project begon de behoeften van veel webmasters te weerspiegelen in plaats van die van één persoonlijke site.
De documentatie verbeterde, randgevallen werden gepatcht en er ontstonden conventies die het makkelijker maakten om op te pikken en te gebruiken.
Een belangrijk keerpunt was PHP 3, dat de kernherschreef en de naam "PHP: Hypertext Preprocessor" introduceerde. Dit was meer dan branding.
De herschrijving maakte de taal consistenter en makkelijker uitbreidbaar, waardoor PHP kon groeien zonder een onhoudbare stapel ad-hoc scripts te worden.
De bredere community drong aan op integraties met tools die ze al gebruikten. Extensies verschenen die PHP verbonden met verschillende databases en services, zodat je niet vastzat aan één setup.
In plaats van "een scriptingtool die HTML produceert" werd PHP een praktische manier om data-gedreven websites te bouwen—gastenboeken, forums, catalogi en vroege e-commerce.
Dat is de sleutelverandering: communitybijdragen voegden niet alleen features toe; ze veranderden PHP's rol van nuttige toolkit naar een gedeeld, uitbreidbaar platform waarop mensen echte projecten durfden te baseren.
PHP werd niet standaard gekozen voor zoveel websites alleen omdat het makkelijk te leren was. Een groot deel van het verhaal is dat de "engine" onder de motorkap een serieuze upgrade kreeg—een upgrade die PHP sneller, consistenter en makkelijker uitbreidbaar maakte.
Zend (opgericht door Andi Gutmans en Zeev Suraski) introduceerde de Zend Engine als nieuwe kern voor PHP. Zie het als het vervangen van de motor terwijl je dezelfde auto behoudt.
Ontwikkelaars konden nog steeds vertrouwde PHP-code schrijven, maar de runtime werd intern beter gestructureerd.
Die structuur maakte het mogelijk:
PHP 4 (gedreven door Zend Engine 1) kwam op het perfecte moment voor het web's "huur een stukje server" model.
Shared hostingproviders konden PHP breed en goedkoop aanbieden, en veel providers deden dat. Die beschikbaarheid werd een groeilus: meer hosts ondersteunden PHP, dus meer mensen gebruikten het; meer gebruik zorgde ervoor dat hosts ondersteuning bleven bieden.
In praktische termen was PHP 4 "goed genoeg, overal." Die ubiquitousheid was net zo belangrijk als welke taalfeature dan ook.
PHP 5 (Zend Engine 2) duwde PHP vooruit voor teams die grotere codebases bouwden. De belangrijkste verandering was sterkere objectgeoriënteerde programmeermogelijkheden: betere class-afhandeling, verbeterde zichtbaarheid en een fundament voor modernere patronen.
Het ging er niet om PHP academisch te maken—maar om het makkelijker te maken reële projecten te organiseren, code te hergebruiken en applicaties onderhoudbaar te houden.
Naarmate PHP zich verspreidde, ontstond druk: mensen gingen verwachten dat oude code bleef werken. Hostingbedrijven, CMS-platforms en bureaus waren afhankelijk van stabiliteit.
Vanaf dat punt ging PHP-evolutie niet alleen over het toevoegen van features—het ging ook over "breek het internet niet."
PHP won niet omdat het op papier de elegantste taal was. Het won omdat het bouwen van nuttige webpagina's directer aanvoelde.
Voor vroege webontwikkelaars—vaak ontwerpers, hobbyisten of kleine bedrijven—verlaagde PHP de time-to-first-working-thing meer dan bijna elk alternatief.
Met PHP was de feedbacklus bijna wrijvingsloos: upload een bestand, ververs de pagina, zie het resultaat. Dat klinkt triviaal, maar het vormde een generatie webbouwers.
Mensen konden starten met één dynamische pagina (een contactformulier, een gastenboek, een teller) en van daaruit uitbreiden.
Vroege webprojecten hadden zelden grote engineeringafdelingen. Ze hadden één ontwikkelaar, misschien twee, en een stapel urgente verzoeken.
PHP paste bij die realiteit: het verminderde de ceremonie rond deployment en maakte incrementele wijzigingen makkelijk uit te rollen.
PHP surfde op een golf van goedkope shared hosting. Veel providers hadden het al voorgeïnstalleerd, dus je had geen speciale infrastructuur of dure servers nodig.
Deployment betekende vaak "bestanden kopiëren", wat paste bij hoe mensen al HTML publiceerden.
Naarmate PHP-adoptie groeide, werd het zichzelf versterkend. Tutorials, snippets, forums en copy-paste voorbeelden waren overal.
Die community-kennis maakte PHP toegankelijk—zelfs wanneer de onderliggende webproblemen dat niet waren.
PHP slaagde niet alleen omdat de taal makkelijk was—het slaagde omdat het een "default home" had op het vroege web.
Die thuisbasis was de LAMP-stack: Linux + Apache + MySQL + PHP. Jarenlang was deze combinatie het standaardrecept voor het draaien van dynamische websites, vooral voor kleine bedrijven en persoonlijke projecten.
Linux en Apache waren breed beschikbaar en goedkoop te draaien. PHP paste netjes in Apache's request/response-model: een bezoeker vroeg een URL op, Apache gaf het verzoek aan PHP en PHP genereerde HTML dynamisch.
Er was geen aparte applicatieserver om te beheren, wat deployments eenvoudig en goedkoop hield.
MySQL maakte het plaatje compleet. PHP's ingebouwde database-extensies maakten het eenvoudig om MySQL te verbinden, queries uit te voeren en resultaten in een webpagina te tonen.
Die nauwe integratie betekende dat een groot deel van de "database-gestuurde sites" gebouwd kon worden met dezelfde bekende tools.
Een belangrijke versneller was shared hosting. Veel hosts boden accounts aan waar PHP en MySQL al waren geconfigureerd—geen systeembeheer nodig.
Met control panels zoals cPanel konden gebruikers een MySQL-database aanmaken, tabellen beheren in phpMyAdmin, PHP-bestanden via FTP uploaden en snel live gaan.
Toen verschenen one-click installers (vaak voor WordPress, forums en winkelwagentjes). Deze installers normaliseerden het idee dat "een website een PHP-app + een MySQL-database is", waardoor PHP voor miljoenen site-eigenaren de weg van de minste weerstand werd.
De stack moedigde een praktisch werkproces aan: bewerk een .php-bestand, ververs de browser, pas SQL aan, herhaal.
Het vormde ook bekende patronen—templates en includes, formulierverwerking, sessions en CRUD-pagina's—en creëerde een gedeeld denkkader voor webbouw dat lang bleef bestaan.
PHP werd niet "overal" puur door zijn syntax. Het werd de standaard omdat complete, installeerbare producten eromheen groeiden—tools die echte zakelijke problemen oplosten met minimale setup.
Contentmanagementsystemen maakten van PHP een one-click beslissing. Platforms zoals WordPress, Drupal en Joomla bundelden de lastige onderdelen—adminpanelen, logins, rechten, thema's en plugins—zodat een site-eigenaar pagina's kon publiceren zonder code te schrijven.
Dat is belangrijk omdat elk CMS zijn eigen gravitationele kracht kreeg: ontwerpers leerden theme-building, bureaus bouwden herhaalbare aanbiedingen en plugin-markten groeiden.
Zodra een klantsite afhankelijk werd van dat ecosysteem, werd PHP keer op keer gekozen—soms zonder dat de klant het zelf besefte.
Webshops en communitysites waren vroege essentials, en PHP paste bij de realiteit van shared hosting.
Software zoals Magento (en later WooCommerce op WordPress), plus forums zoals phpBB, gaven kant-en-klare oplossingen voor catalogi, winkelwagens, accounts en moderatie.
Deze projecten normaliseerden ook een workflow waarbij je een app installeert, in een browser configureert en uitbreidt met modules—precies het soort ontwikkeling dat PHP liet bloeien.
Niet alle PHP-code is publiekelijk zichtbaar. Veel teams gebruiken het voor interne dashboards, admin-tools en eenvoudige API's die betalingen, voorraad, CRM-systemen of analytics koppelen.
Deze systemen verschijnen niet in scans als "welk CMS is dit?", maar houden PHP in dagelijks gebruik.
Wanneer een groot deel van het web op een paar enorme producten draait (vooral WordPress), erft de taal daaronder dat bereik.
PHP's bereik is voor een groot deel het bereik van de ecosystemen erboven—not alleen een reflectie van de taal zelf.
PHP's succes is altijd verweven geweest met pragmatisme—en pragmatisme laat vaak ruwe randen achter.
Veel kritiek heeft echte historische grond, maar niet alles weerspiegelt hoe PHP vandaag wordt gebruikt of geschreven.
Een veelgehoorde klacht is inconsistentie: functienamen volgen verschillende patronen, parameters staan in uiteenlopende volgorde en oudere API's leven naast nieuwere.
Dat is reëel—het resultaat van snel groeien, features toevoegen terwijl het web veranderde en oudere interfaces blijven ondersteunen voor miljoenen bestaande sites.
PHP ondersteunt ook meerdere programmeerstijlen. Je kunt simpele "doe-het-werk" scripts schrijven, of meer gestructureerde, objectgeoriënteerde code.
Critici noemen dat "gemixte paradigma's"; aanhangers noemen het flexibiliteit. Het nadeel is dat teams zonder richtlijnen een ongelijkmatige codekwaliteit krijgen.
"PHP is onveilig" is een simplificatie. De meeste beveiligingsincidenten met PHP komen voort uit applicatiefouten: gebruikersinvoer vertrouwen, SQL opbouwen door strings te plakken, file uploads verkeerd configureren of toegangscontroles vergeten.
Historische defaults van PHP hebben beginners niet altijd naar veilige patronen geleid, en de lage drempel betekende dat veel beginners publieke code uitrolden.
De nauwkeurige conclusie: PHP maakt het makkelijk om webapps te bouwen, en webapps zijn makkelijk fout te doen zonder basisveiligheidshygiëne.
PHP draagt een zware verantwoordelijkheid: het web niet kapot maken.
Die backward compatibility houdt langlopende apps draaiende, maar betekent ook dat legacy-code blijft hangen—soms ver voorbij de houdbaarheidsdatum. Bedrijven besteden soms meer moeite aan het onderhouden van oude patronen dan aan het adopteren van betere.
Eerlijke kritiek: inconsistentie, legacy-API's en ongelijke codebases zijn reëel.
Verouderde kritiek: aannemen dat moderne PHP-projecten eruit moeten zien als begin jaren 2000 PHP, of dat de taal zelf de voornaamste beveiligingszwakte is.
In de praktijk hangt het meestal samen met teampraktijken, niet met het gereedschap.
PHP's reputatie is vaak verbonden aan code uit het verleden: gemengde HTML en logica in één bestand, inconsistente stijlen en "het werkt op mijn server" deploymentgewoonten.
PHP 7 en 8+ voegden niet alleen features toe—ze duwden het ecosysteem richting schoner, sneller en beter onderhoudbaar werken.
PHP 7 bracht grote prestatieverbeteringen door kerninternals te herontwerpen.
In gewone woorden: dezelfde app kon meer verzoeken aan op dezelfde hardware, of goedkoper draaien bij hetzelfde verkeer.
Dat was belangrijk voor shared hosting, drukke WordPress-sites en elk bedrijf dat pagina‑laadtijd in omzet meet. Het maakte PHP opnieuw competitief met nieuwere server-side opties.
PHP 8 introduceerde features die grote codebases makkelijker maken om te begrijpen:
int|string). Dit vermindert giswerk en verbetert tooling.Moderne PHP-projecten vertrouwen meestal op Composer, de standaard dependency manager.
In plaats van libraries handmatig te kopiëren, verklaren teams afhankelijkheden in een bestand, installeren voorspelbare versies en gebruiken autoloading. Dit is een reden dat hedendaagse PHP veel professioneler aanvoelt dan het kopieer-en-plak-tijdperk.
Oud PHP betekende vaak ad-hoc scripts; modern PHP betekent meestal versiebeheer van dependencies, frameworks, getypte code, geautomatiseerde tests en prestaties die standhouden onder echt verkeer.
PHP is geen nostalgische keuze—het is een praktisch gereedschap dat nog steeds goed past bij veel webtaken.
De sleutel is het matchen met je beperkingen, niet je ideologie.
PHP blinkt uit wanneer je bouwt of runt:
Als je project profiteert van “veel ontwikkelaars kennen dit al, en hosting is overal”, kan PHP veel frictie wegnemen.
Overweeg alternatieven als je nodig hebt:
Het kan ook zinvol zijn een ander stack te kiezen wanneer je een gloednieuw product bouwt en sterke defaults wilt voor moderne architectuur (getypte API's, gestructureerde services en duidelijke scheiding van verantwoordelijkheden).
Stel deze vragen voordat je kiest:
Een tijdloze les uit PHP's oorsprongsverhaal is simpel: winnende tools verkleinen de kloof tussen idee en werkende software.
Als je evalueert of je in PHP blijft investeren of een nieuwe service ernaast bouwt (bijvoorbeeld een React-frontend met een Go-API), kan een snel prototype veel onduidelijkheid wegnemen. Platforms zoals Koder.ai zijn gebouwd voor die “ship-first” workflow: je kunt een app beschrijven in chat, een werkend web- of backendproject (React + Go met PostgreSQL) genereren en snel itereren met functies zoals planning mode, snapshots en rollback—en de broncode exporteren wanneer je klaar bent.
Voor meer praktische gidsen, bekijk /blog. Als je deployment- of service-opties vergelijkt, kan /pricing helpen bij het inschatten van kosten.
Rasmus Lerdorf bouwde een set kleine, in C geschreven hulpprogramma's om zijn persoonlijke site te onderhouden: bezoekers bijhouden, paginagedeelten hergebruiken en eenvoudige dynamische inhoud verwerken.
Omdat het doel was repetitief webwerk weg te nemen (niet het ontwerpen van een “perfecte” taal), voelt PHP van meet af aan praktisch: snel te deployen, eenvoudig in HTML in te bedden en gevuld met webgerichte helpers.
In het midden van de jaren 90 bestond het web vooral uit statische HTML. Voor dynamische functionaliteit (formulieren, tellers, gepersonaliseerde inhoud) gebruikte men meestal CGI-scripts, vaak in Perl.
Dat werkte, maar was onhandig voor dagelijkse updates omdat je meestal een apart programma schreef dat HTML uitprintte in plaats van een bestaande HTML-pagina met een paar serverlogica-regels aan te passen.
CGI-programma's draaiden doorgaans als aparte processen per aanvraag en vroegen meer setup (bestandsrechten, serverconfiguratie en een andere manier van denken).
PHP maakte dynamische output dichter bij het idee van “een webpagina bewerken”: schrijf HTML, voeg kleine server-side stukjes toe, upload en vernieuw de pagina.
PHP/FI stond voor “Personal Home Page / Forms Interpreter.” Het was een vroege publieke versie gericht op het bouwen van dynamische pagina's en het verwerken van formulieren.
Het ‘killer’-idee was server-side code direct in pagina's kunnen opnemen en tegelijkertijd ingebouwde gemakken bieden voor veelvoorkomende webtaken (vooral formulieren en basale database-access).
Het verlaagde de drempel voor niet-specialisten: je hield HTML als hoofddocument en voegde kleine dynamische stukjes toe (zoals het tonen van een naam of het doorlopen van resultaten).
Deze werkwijze paste bij hoe mensen sites bouwden op shared hosting—stapsgewijs—zonder meteen een volledig nieuw templating-systeem te hoeven gebruiken.
Zodra PHP publiek werd gedeeld, begonnen andere ontwikkelaars fixes, kleine features en integraties te sturen.
Dat veranderde PHP van “iemand's persoonlijke gereedschapskist” naar een ecosysteem-gedreven project, waarin de behoeften van webmasters (databases, extensies, draagbaarheid) de richting van de taal bepaalden.
PHP 3 was een grote herschrijving die de kern stabieler en makkelijker uitbreidbaar maakte, en introduceerde de naam “PHP: Hypertext Preprocessor.”
In de praktijk was dit het punt waarop PHP minder een verzameling losse scripts werd en meer een consistente, uitbreidbare platformkeuze.
De Zend Engine (ontwikkeld door Andi Gutmans en Zeev Suraski) verbeterde de runtime-internals van PHP—meer structuur, betere prestaties en een duidelijkere route voor extensies.
Dit maakte het mogelijk om PHP breed en goedkoop aan te bieden bij hosts, en teams konden grotere codebases bouwen met voorspelbaarder gedrag.
LAMP (Linux, Apache, MySQL, PHP) werd een standaardrecept voor dynamische sites, vooral op shared hosting.
PHP paste goed in Apache's request/response-model en de databaseconnectiviteit maakte MySQL-ondersteunde pagina's simpel—waardoor miljoenen sites op hetzelfde stack en werkproces gingen vertrouwen.
Modern PHP (7 en 8+) bracht grote snelheidswinst en onderhoudsvriendelijke taalfeatures, terwijl Composer het dependency-beheer standaardiseerde.
Bij het evalueren van PHP: kijk naar je constraints—gebruik je WordPress/Drupal/Magento? Heb je behoefte aan goedkoop en veelvoorkomend hosting? Is incremental modernisering goedkoper dan een rewrite? Als je een bestaand PHP-systeem uitbreidt, is stapsgewijze modernisering vaak praktischer dan alles opnieuw bouwen.