JavaScript is een taal waar ik al jarenlang mee werk, vooral aan de frontend-kant van applicaties en op plekken waar snelheid van ontwikkelen belangrijk is. Hoewel mijn primaire specialisatie tegenwoordig duidelijk bij backend engineering met Java en Kotlin ligt, heeft JavaScript een belangrijke rol gespeeld in mijn ontwikkeling als fullstack developer. In mijn CV staat JavaScript dan ook als een van de technologieën waar ik meerdere jaren ervaring mee heb opgebouwd.
Wat is JavaScript?
JavaScript is de programmeertaal waarop vrijwel het volledige moderne web draait. Waar HTML de structuur bepaalt en CSS verantwoordelijk is voor presentatie, gebruik je JavaScript om gedrag en interactie toe te voegen.
Maar JavaScript is al lang niet meer alleen een taal voor een knop of formulier in de browser. Met Node.js kan dezelfde taal ook aan de backend worden gebruikt en frameworks zoals Vue en Nuxt maken het mogelijk om complete webapplicaties ermee te bouwen.
Dat brede toepassingsgebied is tegelijkertijd de kracht en het risico van JavaScript.
Je kunt er heel snel mee bouwen, maar zonder duidelijke structuur kun je er ook heel snel iets onnodig ingewikkelds mee maken.
Hoe ik naar JavaScript kijk
Ik gebruik JavaScript vooral pragmatisch.
Wanneer ik een gebruikersinterface nodig heb, wil ik niet eerst een compleet technisch landschap optuigen voordat ik iets op het scherm kan krijgen. JavaScript geeft mij samen met Vue en Nuxt de mogelijkheid om relatief snel van een idee naar een werkende interface te gaan.
Voor grotere applicaties kies ik tegenwoordig meestal voor TypeScript boven puur JavaScript. Niet omdat JavaScript onvoldoende krachtig is, maar omdat expliciete types meer structuur brengen zodra een applicatie groeit.
Voor kleine onderdelen, scripts of eenvoudige toepassingen vind ik JavaScript nog steeds prima.
Simpel houden waar dat kan.
JavaScript en structuur
Een van de belangrijkste lessen die ik door de jaren heen heb geleerd, is dat vrijheid binnen een programmeertaal ook discipline vereist.
JavaScript laat technisch gezien enorm veel toe. Dat betekent niet dat je alles wat mogelijk is ook moet gebruiken.
Ik probeer daarom dezelfde principes toe te passen als in mijn backend systemen:
functies en componenten met één duidelijke verantwoordelijkheid
expliciete datastromen
zo min mogelijk verborgen gedrag
logica niet onnodig verspreiden
afhankelijkheden bewust kiezen
abstraheren wanneer daar daadwerkelijk een reden voor is
Een frontend hoeft voor mij niet slim te lijken. Hij moet begrijpelijk zijn.
Hoe ik JavaScript gebruik
Mijn JavaScript-gebruik zit tegenwoordig voornamelijk rondom webapplicaties.
Daarbij werk ik veel met Vue en vooral Nuxt. Ik gebruik de Composition API om functionaliteit logisch te structureren en maak waar relevant gebruik van server-side rendering.
Mijn backend blijft daarbij meestal bewust gescheiden.
JavaScript of TypeScript verzorgt de gebruikerservaring, terwijl Java, Kotlin of afhankelijk van de toepassing Go verantwoordelijk is voor de belangrijkste domeinlogica en verwerking.
Die scheiding vind ik prettig omdat iedere technologie dan wordt ingezet voor waar hij sterk in is.
Waar ik JavaScript heb gebruikt
Een groot deel van mijn praktische JavaScript-ervaring heb ik opgebouwd tijdens mijn periode als Fullstack Developer bij Marvia, waar ik ruim vier jaar werkte aan een SaaS Local Marketing Automation-platform.
Daarnaast heb ik JavaScript gebruikt binnen mijn eigen SaaS-ontwikkeling, waarbij Vue werd ingezet voor de frontend van onder andere Debit55. Die frontend draaide bovenop een architectuur met meerdere backend services en event-driven communicatie.
Daardoor kijk ik niet alleen vanuit het perspectief van een frontend developer naar JavaScript. Ik kijk vooral naar hoe de frontend onderdeel wordt van het volledige systeem.
JavaScript versus TypeScript
Voor professionele applicaties waar meerdere componenten, domeinmodellen en API-contracten samenkomen, heeft TypeScript tegenwoordig mijn voorkeur.
JavaScript geeft veel vrijheid.
TypeScript geeft een gedeelte van die vrijheid op in ruil voor duidelijkheid.
Dat is bij grotere systemen meestal een goede ruil.
Toch vind ik dat je TypeScript niet moet gebruiken om ieder object, ieder resultaat en iedere interne constructie vol te zetten met complexe types. Types moeten begrip toevoegen.
Als het type moeilijker te begrijpen wordt dan de code die het probeert te beschermen, ben je wat mij betreft te ver gegaan.
Wanneer ik JavaScript zou kiezen
Ik zou JavaScript gebruiken wanneer ik:
snel een webinterface wil bouwen
eenvoudige browserlogica nodig heb
een klein script moet realiseren
binnen een bestaand JavaScript-ecosysteem werk
geen voordeel haal uit de extra typeveiligheid van TypeScript
Voor grotere frontend applicaties zou ik meestal direct TypeScript kiezen.
Voor complexe backend systemen ligt mijn voorkeur nog steeds bij Java of Kotlin.
Niet omdat JavaScript dat technisch niet aankan, maar omdat ik voor backend architecturen waarde hecht aan expliciete modellen, voorspelbaarheid en structuur.
Veelgestelde vragen die ik krijg over JavaScript
Gebruik je JavaScript nog veel?
Ja, maar voornamelijk rondom frontendontwikkeling. Mijn dagelijkse specialisatie ligt bij backend engineering, waardoor Java en Kotlin een veel grotere rol spelen.
JavaScript of TypeScript?
Voor kleine toepassingen kan JavaScript prima zijn. Zodra een applicatie groeit of meerdere developers eraan werken, kies ik meestal TypeScript vanwege de extra structuur en typeveiligheid.
Gebruik je JavaScript ook voor backend development?
Ik heb ervaring met Node.js en Express, maar voor serieuze backend platformen kies ik doorgaans Java, Kotlin of soms Go. Die technologieën passen beter bij de systemen die ik meestal ontwerp.
Welk JavaScript-framework gebruik je het liefst?
Vue in combinatie met Nuxt. Ik vind de ontwikkelervaring eenvoudig, snel en overzichtelijk en werk daarbij voornamelijk met de Composition API.
Vind je JavaScript een goede programmeertaal?
Ja, mits je bewust omgaat met de vrijheid die de taal biedt. JavaScript maakt het heel eenvoudig om snel iets te bouwen. De echte uitdaging begint daarna: zorgen dat iemand anders het over een jaar nog steeds eenvoudig kan begrijpen.