Wie een webapplicatie laat ontwikkelen, kiest de programmeertaal zelden zelf: de softwarepartner stelt er een voor. Toch draag jij de gevolgen, jarenlang. De taal bepaalt mede wat onderhoud kost, hoe makkelijk je ontwikkelaars vindt en of je ooit van partner kunt wisselen zonder de applicatie opnieuw te laten ontwikkelen.
Dit artikel beantwoordt eerst welke programmeertalen gangbaar zijn bij webapplicatie ontwikkeling, en geeft je daarna een kader om het voorstel van je bureau te toetsen. Technisch hoef je daarvoor niet te zijn.
Welke programmeertalen worden gebruikt voor webapplicatie ontwikkeling
Een webapplicatie bestaat uit twee lagen. De browserkant is wat je gebruikers zien en aanklikken; de serverkant verwerkt de gegevens, past de bedrijfsregels toe en praat met de database en met andere systemen.
Aan de browserkant valt weinig te kiezen. JavaScript is de taal die browsers zelf uitvoeren, tegenwoordig meestal geschreven als TypeScript: een strengere variant die fouten opspoort voordat de code draait. Frameworks als React en Vue.js bepalen vervolgens hoe de interface is opgebouwd.
Aan de serverkant is de keuze breder. Dit zijn de talen die je in voorstellen voor bedrijfsapplicaties het vaakst tegenkomt:
- PHP, vrijwel altijd met een framework als Laravel of Symfony. Veel ingezet voor webapplicaties en portalen.
- Python, met frameworks als Django of FastAPI. Sterk waar data en AI een rol spelen, omdat de meeste tooling daarvoor in Python is geschreven.
- C# op .NET, de logische keuze in organisaties die al op Microsoft-technologie draaien.
- Java, veel gebruikt in grote organisaties met langlopende systemen.
- JavaScript op de server via Node.js, vaak gekozen als een team aan beide kanten met TypeScript wil werken.
De database is meestal een aparte keuze, bijvoorbeeld PostgreSQL of MySQL, en staat los van de taal. Al deze talen zijn volwassen; op elk ervan draaien dagelijks bedrijfskritische systemen. De taalnaam op het voorstel zegt dus weinig, de onderbouwing erachter zegt alles.
Het framework en de versie zeggen meer dan de taal
Vraag niet alleen welke taal, maar welk framework en welke versie. Een framework is de bouwdoos waarmee een team in die taal werkt: het regelt inloggen, formulieren, beveiliging en de koppeling met de database. Een framework met een grote gemeenschap erachter krijgt beveiligingsupdates en kent veel ontwikkelaars die ermee overweg kunnen.
De versie is het stille risico. Taal- en frameworkversies hebben een ondersteuningsperiode; daarna komen er geen beveiligingsupdates meer. Een applicatie die wordt opgeleverd op een versie die al tegen het einde van die periode loopt, levert je binnen een jaar een upgradeproject op dat niet in de offerte stond.
Beschikbaarheid van ontwikkelaars bepaalt je vrijheid
De belangrijkste toets is niet technisch maar economisch: hoeveel mensen kunnen dit systeem over vijf jaar onderhouden? Bij de talen hierboven is die groep groot. Ontwikkelaars zijn te vinden en bureaus kunnen elkaars werk overnemen.
Een paar voorstellen verdienen extra aandacht. Niet omdat ze per definitie fout zijn, maar omdat ze die groep versmallen:
- een taal die je in geen enkel ander voorstel tegenkomt;
- een framework dat het bureau zelf heeft ontwikkeld en dat buiten dat bureau niemand kent;
- een gesloten low-code- of no-code-platform, waarbij de applicatie alleen binnen dat platform bestaat;
- een framework dat net is uitgekomen en zich in productie nog niet heeft bewezen.
In het slechtste geval blijft er precies één partij over die je applicatie kan onderhouden: je huidige leverancier. Technologie die op indruk is gekozen in plaats van op het werk, is een van de patronen uit vijf redenen waarom webapplicaties falen.
De taal moet passen bij wat je al hebt
Een taalkeuze staat nooit op zichzelf. Draait je organisatie op Microsoft-technologie, met eigen beheerders die daarin thuis zijn, dan is C# op .NET een logischer voorstel dan een taal die niemand intern kent. Heb je al systemen in PHP of Python, dan is daarop aansluiten vaak verstandiger dan een derde taal introduceren.
Kijk ook naar de koppelingen. Een webapplicatie die met je ERP, CRM of boekhoudpakket moet praten, is gebaat bij een taal waarin voor die systemen al kant-en-klare koppelingen bestaan. Weeg daarnaast mee waar de applicatie gaat draaien en wie hem beheert.
Python zodra AI of data in je plannen zit
Het grootste deel van de tooling voor AI en dataverwerking is in Python geschreven. Staat AI op je roadmap, zoals documenten automatisch verwerken of een assistent die met je eigen gegevens werkt, dan hoeft je hele applicatie daarvoor niet in Python te zijn. Gebruikelijk is een aparte Python-service naast de bestaande applicatie: de webapplicatie in de taal die bij het team en het landschap past, de AI-onderdelen in Python.
Wat de taal niet bepaalt
Of je applicatie over vijf jaar nog veilig, snel en aanpasbaar is, hangt minder af van de taal dan van wat eromheen geregeld is. Verouderde, onhoudbare code ontstaat in elke taal; goed onderhouden systemen bestaan in elke taal. Het verschil zit in geautomatiseerde tests, bijgehouden documentatie, een gestroomlijnde manier van live zetten en heldere afspraken over het eigendom van de broncode.
Die onderwerpen werkten we eerder apart uit: hoe je vendor lock-in voorkomt, met de vragen over eigendom en overdracht; waarom goede documentatie je onafhankelijk houdt van je ontwikkelteam; en welke DevOps-practices een softwarepartner op orde moet hebben. Laat een gesprek over de taal nooit de plaats innemen van die vragen.
Zo toets je het voorstel aan tafel
Je hoeft geen code te kunnen lezen om een taalkeuze te beoordelen. Deze vragen leggen bloot of erover is nagedacht:
- Waarom deze taal voor dit vraagstuk, en wat zou het alternatief zijn geweest?
- Welk framework en welke versie, en tot wanneer wordt die ondersteund?
- Hoeveel andere partijen zouden dit kunnen overnemen?
- Hoe sluit de keuze aan op de systemen en de mensen die we al hebben?
- Wat gebeurt er met deze keuze als we later AI of zwaardere dataverwerking toevoegen?
Een partner die hierop concreet antwoordt, in termen van wat het jou oplevert, heeft zijn keuze gemaakt op het werk en niet uit gewoonte. Blijft het antwoord steken bij ‘dit gebruiken we altijd’, dan weet je ook iets.
Zelf werken we bij webapplicaties met Laravel, Vue.js, React, Node.js, TypeScript en PostgreSQL, en met Python voor data en AI; het team kiest wat bij het project past. Het sterkste voorstel begint zelden bij de taal, maar bij je vraagstuk, je bestaande systemen en de mensen die ermee werken. Hoe we dat aanpakken, lees je bij webapplicaties en portalen.