Maarten
Front-end developer
HTML · CSS · JavaScript · React
Front-end developer
Front-end developer inhuren voor interfaces die snel laden, prettig bedienen en ook op een klein scherm overeind blijven: freelance, met 25 jaar ervaring, vanuit Nijmegen en remote door heel Nederland.
Eerder gebouwd voor de Evangelische Omroep, Suitableshop.nl en DVJ Insights.
Eén ervaren freelancer
Front-end developer inhuren voor je interface
Korte audit van de belangrijkste pagina's: laadtijd, responsiviteit en toegankelijkheid. Op basis daarvan een aanpak die past bij het bestaande ontwerp en de mensen die het straks onderhouden, niet bij het nieuwste framework. Vooraf is er een gesprek nodig om te weten wat er speelt, niet andersom.
- Performance- en toegankelijkheidsaudit
- Aanpak per pagina, niet in één keer alles
- Concreet voorstel in fases
- Direct contact, geen tussenlagen
Voorbeelden van opgeleverd werk
Een webshop die technisch én commercieel sterker staat
Van een traag, slecht converterend platform naar een snelle webshop die soepel samenwerkt met de systemen erachter.
Het Tweede Scherm: meekijken én meedoen
Interactief meedoen op tablet en smartphone tijdens het tv-kijken, volledig multichannel en gebouwd op WordPress.
Een website die de expertise van DVJ Insights uitstraalt
Website voor het onderzoeksbureau op basis van de bestaande branding, ontwikkeld op WordPress.
Waarom een front-end developer inhuren meer is dan een mooi ontwerp
Een front-end developer inhuren wordt vaak gelezen als "iemand die het ontwerp omzet naar een werkende pagina", en dat klopt, maar het is het kleinste deel van het werk. Een interface moet ook snel laden op een matige mobiele verbinding, bedienbaar zijn met alleen een toetsenbord, blijven werken als een API traag antwoordt, en over een jaar nog uit te breiden zijn zonder dat elke wijziging drie andere onderdelen breekt. Design bepaalt hoe iets eruitziet; de front-end eronder bepaalt of het ook echt werkt voor iedereen die er gebruik van maakt.
Een freelance front-end developer inhuren betekent, in de praktijk, iemand die het ontwerp, de techniek erachter en de mensen die het straks onderhouden allebei kent: HTML en CSS als fundament, JavaScript of een framework als React waar dat nodig is, en de discipline om niet meer complexiteit toe te voegen dan de situatie vraagt. Vanuit Nijmegen wordt er gewerkt voor opdrachtgevers door heel Nederland, meestal op afstand en af en toe op locatie voor een sessie met het designteam of de rest van de developers. Vijfentwintig jaar ervaring betekent vooral: weten welke technische keuzes over een paar jaar spijt opleveren, en welke gewoon degelijk blijven werken.
Elk traject begint met dezelfde vraag: wat merkt de bezoeker eigenlijk van de huidige interface, en waar zit de meeste wrijving? Een audit van de belangrijkste pagina's brengt laadtijd, responsiviteit en toegankelijkheid in kaart, meestal met de Core Web Vitals als meetlat. Op basis daarvan ontstaat een aanpak die past bij de situatie: een bestaand ontwerp dat beter geïmplementeerd moet worden, een component-bibliotheek die orde nodig heeft, of een interactieve interface die vanaf nul wordt opgebouwd. Soms is dat een gerichte ingreep op een paar pagina's, soms een langer traject in fases — een volledige rebuild is zelden de eerste stap, ook niet wanneer de bestaande code er rommelig uitziet.
Voor wie dit werkt, loopt uiteen: een marketingteam wiens site technisch achterloopt op de rest van de merkuitingen, een productteam dat een dashboard nodig heeft dat ook op een tablet prettig werkt, of een bureau dat voor een project tijdelijk extra front-end capaciteit zoekt naast het eigen team. In alle gevallen gaat het om dezelfde behoefte: iemand die het ontwerp serieus neemt én weet wat er onder de motorkap gebeurt, zonder daar een account manager tussen te zetten.
Wat een front-end project precies nodig heeft, is zonder de bestaande pagina's gezien lastig te zeggen. Daarom begint het meestal met een kennismakingsgesprek: een half uur om te horen wat er speelt, gevolgd door een eerlijk beeld van waar de interface staat en welke vervolgstappen logisch zijn. Geen verplichting, en geen verkooppraatje over een framework dat toevallig net getest wordt.
Gebouwd voor
Klaar om je site sneller en toegankelijker te maken?
Wat een front-end developer oplevert
Zelden is een compleet nieuw framework de oplossing; meestal levert een gerichte ingreep op het onderdeel met de meeste wrijving al het meeste op, zonder de rest van de site te hoeven aanraken. Een paar voorbeelden van wat er dan concreet verandert.
-
Snellere laadtijden
Een meting op de Core Web Vitals laat zien waar de tijd echt naartoe gaat. Op basis daarvan worden afbeeldingen, blokkerende scripts en lettertypen gericht aangepakt, in plaats van te gokken naar de oorzaak.
-
Een layout die op elk scherm klopt
Een ontwerp dat op desktop prima staat, maar op een klein scherm moet knellen noch overlopen. Meestal is dat op te lossen in een paar componenten, zonder de hele opzet van de site aan te passen.
-
Een opgeruimde componentstructuur
Eén herbruikbare knop of kaart in plaats van vijf net iets andere versies door de hele codebase heen. Een kleine, gedeelde set componenten zorgt dat een wijziging op één plek doorwerkt in plaats van overal apart.
-
Toegankelijke bediening voor iedereen
Formulieren die met het toetsenbord te bedienen zijn, voldoende contrast en duidelijke labels voor een schermlezer, meestal op te lossen zonder het ontwerp overnieuw te doen of nieuwe componenten te bouwen.
-
Opgeruimde, onderhoudbare JavaScript
Losse scripts door de hele pagina vervangen door een duidelijke structuur, zodat helder blijft wat er gebeurt bij een klik. Wat allang niet meer gebruikt wordt, gaat eruit.
-
Advies over het bestaande ontwerp of een nieuwe front-end
Doorbouwen op het huidige ontwerp, een designsysteem optuigen of een nieuwe front-end vanaf nul: een audit van de belangrijkste pagina's laat zien wat het team dat de interface straks onderhoudt het beste past, in plaats van te kiezen voor het nieuwste framework.
Benieuwd wat een korte audit van jouw interface oplevert?
Interactieve interfaces die op tv-tempo meedraaien
Voor de Evangelische Omroep is het Tweede Scherm ontwikkeld: een interactieve laag waarmee kijkers tijdens een uitzending meedoen vanaf hun eigen tablet of smartphone. De interface moest in het tempo van live-tv meebewegen, op meerdere apparaten tegelijk, zonder dat een trage verbinding de ervaring verstoort.
Dat soort realtime interactie stelt andere eisen aan de front-end dan een gewone contentpagina: de interface moet direct reageren op invoer, ook als de achterliggende data net iets later binnenkomt, en overeind blijven als duizenden kijkers tegelijk op hetzelfde moment iets aanklikken.
Diezelfde aandacht voor directe feedback en soepel gedrag onder druk is precies waar interactieve dashboards en formulieren op vastlopen wanneer de front-end er niet voor is ontworpen. Een los knopje dat traag reageert valt in een demo niet op, maar wel zodra er echt gebruikers achter zitten.
Snellere pagina's, soepelere winkelervaring
Voor Suitableshop is gewerkt aan een webshop die sneller laadt en soepeler werkt, van de eerste weergave van de productpagina tot het bestelproces op een telefoon. Snelheid en winkelgemak op mobiel zijn bij een webshop geen apart onderwerp naast de techniek: het is de techniek.
Een productpagina die zwaar aanvoelt zit meestal vol met dezelfde soort problemen: te grote afbeeldingen, scripts die inladen voordat ze nodig zijn, en een layout die op mobiel meer verschuift dan nodig. Elk van die problemen is los op te lossen, zonder de hele winkel opnieuw te bouwen.
Hetzelfde patroon geldt voor elke site waar bezoekers vooral op een telefoon binnenkomen: de eerste seconden bepalen of iemand blijft kijken of wegklikt, en die seconden zitten in de front-end. Een winkelwagentje dat traag bijwerkt of een filter dat hapert, telt in die eerste indruk net zo zwaar mee als de laadtijd zelf.
Twijfel over de volgende stap? Een half uur meedenken helpt vaak al.
Front-end werk dat regelmatig terugkomt
Van een bestaand ontwerp goed implementeren tot een interactief dashboard vanaf nul: onderstaand het werk dat het vaakst terugkomt, telkens toegesneden op wat er al staat, op het team en op wie het straks onderhoudt.
Component-based interfaces
Herbruikbare bouwstenen in plaats van copy-paste HTML, zodat een wijziging op één plek doorwerkt in plaats van overal apart te moeten worden aangepast.
Performance-optimalisatie
Afbeeldingen, lettertypen en scripts zo laden dat de pagina snel bruikbaar aanvoelt, gemeten op de Core Web Vitals in plaats van op een onderbuikgevoel.
Toegankelijkheid (a11y)
Bediening met toetsenbord, duidelijke labels voor schermlezers en voldoende contrast, getoetst aan de WCAG-richtlijnen in plaats van achteraf gecontroleerd.
Design-naar-code
Een ontwerp uit Figma of een vergelijkbaar tool omzetten naar een werkende, responsieve interface die op elk scherm klopt, inclusief de tussenliggende breekpunten.
Interactieve dashboards
Data die realtime of near-realtime verandert overzichtelijk weergeven, zonder dat de interface daaronder gaat haperen zodra er veel tegelijk binnenkomt.
Legacy front-end opschonen
Losse scripts en verouderde libraries stap voor stap vervangen door een structuur die een team wel kan onderhouden, zonder de site tijdenlang plat te leggen.
- JavaScript
- TypeScript
- HTML
- CSS
- React
- Next.js
- Tailwind CSS
- jQuery
- Bootstrap
- PHP
- Git
Veelgestelde vragen
Een aantal vragen dat regelmatig terugkomt bij het inhuren van een front-end developer, van framework-keuze tot toegankelijkheid en samenwerking met een backend-team. Staat je eigen vraag er niet bij, stel 'm gewoon in het kennismakingsgesprek.
Werk je met React, of ook zonder framework?
Met beide. React of Next.js waar interactiviteit dat vraagt, en gewoon HTML, CSS en een beetje JavaScript waar dat sneller, lichter en makkelijker te onderhouden is. De keuze hangt af van het project en van wie het straks beheert, niet van een voorkeur voor een bepaald framework.
Kun je binnen een bestaand ontwerp of designsysteem werken?
Ja, dat is meestal het uitgangspunt. Een bestaand ontwerp of design-systeem wordt zo veel mogelijk gerespecteerd; alleen waar het de bediening of de snelheid in de weg zit, is bijstellen aan de orde, in overleg met wie het ontwerp heeft gemaakt.
Wat doe je aan toegankelijkheid?
Toetsenbordbediening, duidelijke labels voor schermlezers, voldoende contrast en logische leesvolgorde, getoetst aan de WCAG-richtlijnen. Dat hoort standaard bij het werk, niet bij een aparte aanvraag achteraf.
Kun je performance-problemen oplossen op een bestaande site?
Meestal wel. Eerst een meting op de Core Web Vitals om te zien waar de tijd echt naartoe gaat: te grote afbeeldingen, blokkerende scripts, een traag ladend lettertype of een layout die tijdens het laden nog verschuift. Die meting voorkomt dat er wordt gegokt naar de oorzaak of dat een dure serverupgrade wordt voorgesteld voor een probleem dat in de front-end zit. Op basis daarvan volgen gerichte verbeteringen: afbeeldingen in het juiste formaat en met lazy loading, scripts die pas laden als ze nodig zijn en lettertypen die niet de hele pagina laten wachten. Dat gebeurt zonder de hele site opnieuw te bouwen of van CMS te wisselen, meestal pagina voor pagina, zodat elke verbetering meetbaar is voordat de volgende aan de beurt komt.
Werk je samen met een backend-developer of PHP developer?
Regelmatig, en ook zelfstandig richting een bestaande API of backend. Voor het PHP- of Laravel-gedeelte eronder is er ook de mogelijkheid dat te combineren, zodat er maar één aanspreekpunt nodig is.
Wat kost een front-end traject?
Dat hangt af van de omvang en de vorm: een uurtarief of een vaste prijs per fase. Een gerichte performance- of toegankelijkheidsfix op een paar pagina's leent zich meestal voor een uurtarief; een groter traject, zoals een nieuw designsysteem of een interactief dashboard, past beter bij een vaste prijs per fase. De eerste stap is een audit van de belangrijkste pagina's: laadtijd, responsiviteit en toegankelijkheid, gemeten in plaats van ingeschat. Die audit laat zien hoeveel werk er precies nodig is en welke onderdelen de meeste winst opleveren, waarna er een concreet beeld van de omvang ontstaat. Pas daarna beslis je zelf of en hoe je verder gaat, zonder verplichting vooraf en zonder dat er meteen een compleet nieuw framework wordt voorgesteld terwijl een gerichte aanpassing net zo goed volstaat.
Werk je ook met TypeScript?
Ja, waar een project daarmee gebaat is. TypeScript voorkomt een deel van de bugs die je pas in productie tegenkomt, vooral in een codebase die door meerdere mensen wordt onderhouden. Voor een kleine, overzichtelijke site is gewoon JavaScript vaak voldoende.
Interface die beter moet?
Een half uur bellen om de belangrijkste pagina's en de knelpunten te bespreken, en welke aanpak daar het best bij past: gericht verbeteren, een designsysteem opzetten of iets nieuws bouwen. Geen verplichting, en ook geen kant-en-klaar advies voordat er is meegekeken naar wat er nu al staat.
