

Official logo of Basque Country's public health care service: Osak

256_cta-background.webp

384_cta-background.webp

640_cta-background.webp

750_cta-background.webp

828_cta-background.webp

thumbnail_cta-background.webp

osakidetza-logo

Daar hebben wij de oplossing voor

Wilt u efficiënter werken? 



Atmosphere of azure electric sky, with water, slope,

1080_background.webp

1200_background.webp

256_background.webp

384_background.webp

640_background.webp

750_background.webp

828_background.webp

thumbnail_background.webp

atmosphere-water-sky-azure-electricity-astronomical-object-slope-electric-blue

1080_zen-logo-white.webp

1200_zen-logo-white.webp

256_zen-logo-white.webp

384_zen-logo-white.webp

640_zen-logo-white.webp

750_zen-logo-white.webp

828_zen-logo-white.webp

thumbnail_zen-logo-white.webp

zen-logo-white.webp

ZEN Software

1080_zen-logo-black.webp

1200_zen-logo-black.webp

256_zen-logo-black.webp

384_zen-logo-black.webp

640_zen-logo-black.webp

750_zen-logo-black.webp

828_zen-logo-black.webp

thumbnail_zen-logo-black.webp

západoslovenská energetika-logo

Projectversterking 

Nieuw Softwareproject / Modernisering 

Productivity (Agile Analytics)

Onze expertises

Over ons

Nieuws

Contact

Succes! Je bent toegevoegd aan onze e-maillijst.

Abonneer u op onze e-maillijst en we houden u op de hoogte van nieuws en publicaties van ZEN Software

Abonneer op de nieuwsbrief van ZEN Software

1080_Zen-software-kantoor-9.webp

1200_Zen-software-kantoor-9.webp

1920_Zen-software-kantoor-9.webp

2048_Zen-software-kantoor-9.webp

256_Zen-software-kantoor-9.webp

384_Zen-software-kantoor-9.webp

3840_Zen-software-kantoor-9.webp

640_Zen-software-kantoor-9.webp

750_Zen-software-kantoor-9.webp

828_Zen-software-kantoor-9.webp

thumbnail_Zen-software-kantoor-9.webp

Zen-software-kantoor-9.webp

Nieuw Softwareproject / Modernisering

1080_Frame 30 (3).webp

1200_Frame 30 (3).webp

256_Frame 30 (3).webp

384_Frame 30 (3).webp

640_Frame 30 (3).webp

750_Frame 30 (3).webp

828_Frame 30 (3).webp

thumbnail_Frame 30 (3).webp

Frame 30 (3).webp

- Snel een werkende oplossing nodig? Wij leveren software die direct inzetbaar is.  
        
- Alles inbegrepen: van functionele documentatie tot teamtraining. 
       
- Agile gebouwd met constante bijstuurbaarheid per sprint.  

Turn-Key Software Development

Software, Development



A computer and peripheral setup on a desk with the "WHER LLC

256_computer-personal-computer-furniture-peripheral-computer-keyboard-computer-monitor-table-computer-desk

384_computer-personal-computer-furniture-peripheral-computer-keyboard-computer-monitor-table-computer-desk

thumbnail_computer-personal-computer-furniture-peripheral-computer-keyboard-computer-monitor-table-computer-desk

computer-personal-computer-furniture-peripheral-computer-keyboard-computer-monitor-table-computer-desk

- Houd software en infrastructuur actueel, veilig en toekomstklaar.  
        
- Eliminatie van legacy-opbouw en implementatie van een robuuste architectuur.  
       
- Veilige DevOps-integratie met ingebouwde security.  

Applicatiebeheer en Vernieuwing

Applicatiebeheer

1080_Frame 30 (2).webp

1200_Frame 30 (2).webp

256_Frame 30 (2).webp

384_Frame 30 (2).webp

640_Frame 30 (2).webp

750_Frame 30 (2).webp

828_Frame 30 (2).webp

thumbnail_Frame 30 (2).webp

Frame 30 (2).webp

- **OnlyCloud:** Snelheid en schaalbaarheid voor jouw contentplatform of e-commerceomgeving.  
        
- **Veilige Cloud:** Secure by Design landing zones in AWS en GCP.  
       
- **Europese Cloud:** Volledig EU-gehost en compliant met GDPR, NIS2 en DORA.  

Cloud & Databeveiliging

Cloud, Databeveiliging

1080_Frame 31 (1).webp

1200_Frame 31 (1).webp

256_Frame 31 (1).webp

384_Frame 31 (1).webp

640_Frame 31 (1).webp

750_Frame 31 (1).webp

828_Frame 31 (1).webp

thumbnail_Frame 31 (1).webp

Frame 31 (1).webp

- Jouw onzichtbare AI-collega die technische schuld aanpakt vóórdat het problemen worden.  
      
- Automatische logging en testdekking voor lagere onderhoudskosten.  

De Softwaremonteur (AI-onderhoud)  

Softwaremonteur

Wat dertig minuten wachten per engineer per dag echt kost

ajet8k.webp

Een half uur per dag. Zo weinig lijkt het. Maar reken het door en het is €5.000 per engineer per jaar, of een half miljoen euro bij honderd engineers — geld dat op geen enkele regel van je P&L staat en dat niemand ooit heeft goedgekeurd.

Een half uur per dag. Zo weinig lijkt het.

Je wacht op een build. Je wacht tot iemand je pull request bekijkt. Je wacht op een omgeving die vrijkomt, op een goedkeuring, op een pipeline die twaalf minuten doet over iets wat in twee zou moeten. Niemand noteert het, want het voelt niet als tijd die je kwijtraakt. Het voelt als het werk.

Reken het door en het is €5.000 per engineer per jaar. Bij honderd engineers een half miljoen euro. Elk jaar, en op geen enkele regel van je P&L.

Er zit geen truc in. Je kunt hem zelf natrekken met je eigen cijfers:

- Een half uur per werkdag is **2,5 uur per week**.
- Bij ongeveer **220 werkbare dagen** per jaar is dat **110 uur per engineer per jaar**.
- Reken je met een belaste kostprijs van zo’n **€45 per uur**, dan kom je op **€4.950** — afgerond €5.000.
- Honderd engineers: **€495.000 per jaar**.

Vul gerust je eigen tarief in. Het punt verandert niet: dit is geen randverschijnsel, het is een salarispost ter grootte van een klein team, en er staat geen factuur tegenover.

Als je erop gaat letten, blijkt het bijna nooit één groot blok te zijn. Het zijn kleine stukjes die zich opstapelen:

- **Wachten op builds en tests.** Een pipeline van acht minuten die je vijf keer per dag draait, is veertig minuten. Draait hij niet betrouwbaar, dan draai je hem vaker.
- **Wachten op review.** Meestal de grootste post, en bijna nooit apart gemeten. Je pull request staat klaar; je collega zit in een meeting.
- **Wachten op omgevingen.** Één staging, drie teams.
- **Wachten op goedkeuring.** Iemand moet een vinkje zetten en die iemand heeft vandaag iets anders te doen.
- **De verborgen kosten van het schakelen.** Dit is de pijnlijkste. Vijftien minuten wachten kost je zelden vijftien minuten: je begint aan iets anders, en de weg terug naar waar je was kost nog eens tien.

Cloudkosten zie je, want er komt een factuur. Licenties zie je, want er komt een factuur. Wachttijd komt van niemand, dus komt hij nergens binnen.

Er is ook geen moment waarop iemand een besluit neemt. Niemand heeft ooit goedgekeurd dat de pipeline acht minuten duurt; hij is er in de loop van twee jaar naartoe gegroeid, stap voor stap, en elke afzonderlijke stap was verdedigbaar.

En de mensen die er het meest last van hebben, zijn precies de mensen die het het minst snel melden. Wachten voelt niet als een probleem dat je escaleert. Het voelt als hoe het werk nu eenmaal is.

Dit is het deel dat de meeste teams verrast.

Als code sneller geschreven wordt, wordt er niet minder gewacht — er wordt méér gewacht. Meer wijzigingen bereiken sneller de wachtrij voor review. Meer pull requests concurreren om dezelfde reviewers. Meer builds vechten om dezelfde runners. De bottleneck verdwijnt niet, hij verschuift naar de plek waar geen model bij kan.

Dat is precies waarom code goedkoper maken de kosten niet wegneemt maar concentreert. We hebben dat argument uitgewerkt in [onze kijk op AI in softwareontwikkeling](/ai-solutions): zodra schrijven niet langer je beperking is, wordt alles eromheen je beperking — en dan pas blijkt of je dat ooit gemeten hebt.

Je hoeft hier geen groot programma voor op te tuigen. Drie dingen brengen het grootste deel in beeld:

- **Splits je lead time op in fases.** Eén getal van commit tot productie verbergt precies wat je zoekt. Zodra je schrijven, wachten op review, testen en uitrollen apart ziet, springt de grootste post er meteen uit.
- **Meet review-latency apart.** De tijd tussen “klaar voor review” en “iemand kijkt ernaar”. In de meeste teams is dit de grootste enkele post, en bijna nergens staat hij op een dashboard.
- **Meet de doorlooptijd van je pipeline, niet alleen of hij slaagt.** Slagingspercentage zegt niets over de tijd die je eraan kwijt bent.

Meet een maand voordat je iets verandert. Zonder nulmeting kun je achteraf niet aantonen dat je iets verbeterd hebt, en dan wint degene met de sterkste mening.

De ingrepen zijn zelden spectaculair, en dat is precies waarom ze blijven liggen.

- **Spreek een reviewtermijn af.** “Pull requests onder de 300 regels worden binnen 24 uur bekeken” haalt vaak meer weg dan welke technische ingreep ook.
- **Maak je pull requests kleiner.** Kleinere wijzigingen worden sneller bekeken, en de wachttijd daalt harder dan de omvang.
- **Versnel je pipeline met caching en parallelle tests.** Acht minuten naar drie is over honderd engineers een aanzienlijk bedrag.
- **Geef elke wijziging een eigen omgeving** in plaats van te wachten op de gedeelde staging.
- **Haal goedkeuringen weg die niets tegenhouden.** Een vinkje dat altijd gezet wordt, is geen controle maar vertraging.

Halveer je die dertig minuten, dan haal je bij honderd engineers een kwart miljoen euro per jaar terug. Dat is geen besparing die je hoeft te bevechten in een budgetronde — je hoeft alleen te weten dat hij er is.

Wachttijd is de grootste kostenpost die niemand op zijn begroting heeft staan.

Een half uur per engineer per dag is €5.000 per jaar per persoon en een half miljoen bij honderd. Het staat op geen factuur, niemand heeft het goedgekeurd, en het groeit vanzelf terwijl je nergens op let.

En zodra AI het schrijven versnelt, wordt dit het enige dat er nog toe doet. Meet het voordat je erin investeert, anders weet je straks alleen dat je sneller code produceert — niet of je sneller iets oplevert.

DORA-metrics lezen als AI de helft van je commits schrijft

aq0mfl.webp

Je DORA-dashboard toont nog steeds dezelfde vier getallen. Alleen betekenen ze niet meer hetzelfde. Zodra een flink deel van je code niet meer met de hand geschreven wordt, verschuift wat elk van die metrics je vertelt — en de naïeve lezing wijst precies de verkeerde kant op.

Je DORA-dashboard toont nog steeds dezelfde vier getallen. Alleen betekenen ze niet meer hetzelfde.

Zodra een flink deel van je code niet meer met de hand geschreven wordt, verschuift wat elk van die metrics je vertelt. Sommige gaan omhoog zonder dat er iets verbeterd is. Eén wordt plotseling veel belangrijker dan de rest. En de naïeve lezing — “onze deployment frequency stijgt, dus het gaat goed” — wijst precies de verkeerde kant op.

De vier DORA-metrics meten je **software delivery**, niet je productiviteit. Dat onderscheid is altijd al belangrijk geweest, maar met AI in de mix wordt het bepalend.

- **Deployment frequency** — hoe vaak je naar productie brengt.
- **Lead time for changes** — hoe lang het duurt van commit tot productie.
- **Change failure rate** — welk deel van je wijzigingen problemen veroorzaakt.
- **Time to restore** — hoe snel je herstelt als het misgaat.

Geen van deze vier meet hoeveel code je schrijft. Dat was ooit een detail. Nu is het de kern: code schrijven is niet langer je bottleneck, dus een metric die code-volume negeert is precies wat je nodig hebt.

Deployment frequency stijgt. Dat zegt minder dan je denkt.

Dit is de metric die het snelst beweegt als je AI-tooling invoert, en de metric die het makkelijkst misleidt.

Meer wijzigingen komen sneller klaar, dus er gaan meer wijzigingen naar productie. Je grafiek gaat omhoog. Iemand zet hem in een presentatie.

Maar deployment frequency meet beweging, geen vooruitgang. Als de extra deploys bestaan uit wijzigingen die niemand gevraagd heeft, of uit correcties op wijzigingen van vorige week, dan is je grafiek een teller van activiteit. Kijk er dus nooit naar zonder de change failure rate ernaast te leggen. Stijgen ze samen, dan is er geen winst — dan is er alleen meer verkeer.

Lead time: de code-fase krimpt, de rest niet

Lead time for changes is een optelsom: nadenken, schrijven, reviewen, testen, wachten op goedkeuring, uitrollen.

AI verkort betrouwbaar precies één van die stappen. De rest blijft staan waar hij stond.

Dat betekent dat je totale lead time veel minder daalt dan je verwacht — en dat de verhouding binnen die optelsom scheeftrekt. Waar schrijven vroeger misschien een derde van de doorlooptijd was, is het nu een fractie, en is wachten op een reviewer of op een pipeline verhoudingsgewijs veel dominanter geworden.

Dat is geen tegenvaller, dat is de meest bruikbare informatie die je uit deze metric kunt halen. Splits je lead time op in fases zodra je AI serieus inzet. Zonder die opsplitsing zie je één getal dat licht verbetert; mét die opsplitsing zie je precies waar je volgende uur winst ligt.

Change failure rate wordt je belangrijkste getal

Als code goedkoop wordt om te maken, wordt het duur om te vertrouwen.

Dat maakt de change failure rate de metric waar je het scherpst op moet letten. Niet omdat AI-code per se slechter is — dat argument is grotendeels achterhaald — maar omdat er méér van komt, sneller, en met minder mensen die elke regel echt gelezen hebben.

Twee dingen om in de gaten te houden. Ten eerste een stijging die samenvalt met je AI-invoering: dat is het signaal dat je snelheid je controlemechanismen voorbij is gelopen. Ten tweede, en subtieler, een change failure rate die *gelijk blijft* terwijl je deployment frequency verdubbelt. Dat betekent in absolute zin twee keer zoveel incidenten. Percentages verhullen dat.

Time to restore verandert nauwelijks — en dat is het punt

Van de vier metrics is dit degene die het minst reageert op AI-tooling, en juist daarom is hij zo informatief.

Herstellen na een incident hangt af van je observability, je runbooks, je rollback-mechanismen en of de juiste persoon bereikbaar is. Een model dat sneller code schrijft, raakt daar niets van.

Dus als je deployment frequency omhoog gaat, je lead time daalt en je time to restore blijft precies waar hij was, dan heb je de risicokant van je systeem niet meegeschaald met de snelheidskant. Dat is een prima situatie om in te zitten zolang je het wéét, en een uitstekende manier om verrast te worden als je het niet meet.

DORA blijft belangrijk, maar het is niet meer voldoende. Drie aanvullingen die in een AI-zware workflow het meeste opleveren:

- **Review-latency.** De tijd tussen “klaar voor review” en “gereviewd”. Dit is in de meeste teams inmiddels de grootste enkele post in je lead time, en hij wordt zelden apart bijgehouden.

- **Rework-ratio.** Welk deel van je wijzigingen binnen bijvoorbeeld twee weken alweer aangeraakt wordt. Stijgt dit terwijl je sneller levert, dan produceer je herstelwerk in plaats van vooruitgang.

- **Aandeel AI-ondersteunde wijzigingen.** Je hoeft niet elke regel te herleiden, maar zonder enige indicatie kun je geen enkele uitspraak doen over wat AI je gebracht heeft. Zelfs een grove markering op PR-niveau maakt het verschil tussen meten en gokken.

Begin met een nulmeting vóór je AI-tooling breed uitrolt. Zonder die basislijn kun je achteraf niets aantonen, en precies dát is waar de meeste discussies over AI-investeringen op stuklopen: iedereen heeft een mening, niemand heeft een grafiek van ervoor.

Splits daarna je lead time op in fases, en zet review-latency en rework-ratio ernaast. Bekijk change failure rate altijd in absolute aantallen naast het percentage.

Dit is precies het soort meting waar onze Agile Analytics-engine voor gebouwd is: DORA en SPACE naast elkaar, met de fases uitgesplitst, zodat je ziet waar je doorlooptijd werkelijk heen gaat in plaats van één samengevat getal.

AI verandert je DORA-metrics niet. Het verandert wat ze betekenen.

Deployment frequency wordt gevoeliger voor ruis. Lead time verbetert minder dan verwacht, en verschuift van schrijven naar wachten. Change failure rate wordt je belangrijkste signaal. Time to restore beweegt nauwelijks, en verraadt daarmee of je risicobeheersing is meegegroeid.

Lees ze samen, in absolute aantallen zowel als percentages, met je lead time opgesplitst. Dan meet je wat AI werkelijk heeft opgeleverd — in plaats van te vieren dat de grafiek omhoog loopt.

Een PWA bouwen in 2026: wat je als React-developer écht moet leren

ChatGPT Image May 28, 2026, 01_51_40 PM.webp

Heb je al React-applicaties gebouwd, dan valt een Progressive Web App waarschijnlijk reuze mee.

De term heeft nog altijd iets van 2019 over zich. PWA's werden toen aangeprezen als “websites die zich gedragen als native apps” en zouden en passant de app stores overbodig maken. Die voorspelling is… wisselend oud geworden.

Heb je al React-applicaties gebouwd, dan valt een Progressive Web App waarschijnlijk reuze mee.
     
De term heeft nog altijd iets van 2019 over zich. PWA's werden toen aangeprezen als “websites die zich gedragen als native apps” en zouden en passant de app stores overbodig maken. Die voorspelling is… wisselend oud geworden.
     
Maar ondertussen zijn PWA's stilletjes gewoon nuttig geworden.
     
Voor interne bedrijfstools, klantportalen, webshops, boekingsflows, buitendienst-apps, dashboards en producten waarbij “installeerbaar zijn” zwaarder weegt dan een plek in de App Store, zijn ze vaak precies de praktische tussenweg tussen website en mobiele app.
    
Het goede nieuws: ben je al thuis in React, Next.js, Vite of moderne frontend-tooling, dan ben je er dichterbij dan je denkt.
     
Het slechte nieuws: er zijn een paar concepten die webdevelopers stelselmatig onderschatten.

Om te beginnen: een PWA is niet “even een manifest toevoegen”

Veel tutorials laten PWA-ontwikkeling verdacht simpel lijken.
     
Voeg een ```manifest.json``` toe. Registreer een service worker. Toon een install-prompt. Klaar.
     
Technisch gezien: ja.
     
Maar het lastige deel zit in het doordenken van offlinegedrag, caching, updates en verwachtingen van gebruikers.
     
Gebruikers vergeven een website dat hij herlaadt. Ze vergeven een app niet dat hij zich onvoorspelbaar gedraagt. Dat legt de lat een stuk hoger.
     
Als jouw geïnstalleerde app zomaar verouderde data laat zien, na een deploy stukgaat of weigert te updaten door een te fanatieke cache, dan behandelen mensen hem niet langer als een website maar als kapotte software.
      
Wat het op dat moment, eerlijk is eerlijk, ook is.

1. Je moet service workers begrijpen (ook als je ze verafschuwt)

Dit is de grootste omslag in je denken.
       
Een service worker is in feite een netwerklaag tussen jouw app en de browser. Hij bepaalt wat er gecachet wordt, wanneer requests onderschept worden en wat er moet gebeuren als het internet ermee ophoudt.
       
Je hoeft geen expert in browser-internals te worden, maar je moet wel snappen:
      
- Cache-first versus network-first strategieën
     
- Assets cachen versus API-responses cachen
     
- Offline fallbacks
     
- De valkuilen van de update-lifecycle
      
- De basis van background sync
     
Het vervelende is dat service workers op buitengewoon verwarrende manieren kunnen falen.
     
Je deployt een fix. Gebruikers zien nog steeds de oude versie. Je leegt de cache. Nog steeds stuk. Je twijfelt even aan de werkelijkheid.
      
Uiteindelijk ontdek je dat de service worker beleefd oude assets staat uit te serveren, in de overtuiging dat hij je helpt.
     
Beschouw het als een inwijdingsritueel.

- ```Workbox```
      
- ```vite-plugin-pwa```
     
- ```next-pwa``` (als je nog op Next.js zit en een shortcut zoekt)
      
Je kunt service workers prima met de hand schrijven. De meeste teams besluiten op enig moment dat het leven daar te kort voor is.

Gewone webapps komen weg met slordige aannames, zoals “even herladen lost het op”. Bij een PWA verdwijnt dat vangnet.
      
Zodra installeerbaarheid in beeld komt, telt je cachingstrategie veel zwaarder dan mensen verwachten. Statische assets, API-responses, afbeeldingen en fonts gedragen zich allemaal anders. De verleiding is om alles keihard te cachen, want de performance voelt fantastisch. En dan zitten je gebruikers drie uur lang naar verouderde productdata te kijken.
      
Of erger: de app gaat na een deploy stuk omdat gecachte assets niet meer bij de nieuwe build passen.
     
Het is balanceren: snel genoeg om als app te voelen, vers genoeg om betrouwbaar te blijven.
      
Dat klinkt eenvoudig, tot er echte gebruikers opduiken.

- Het Application-tabblad in je browser DevTools
      
- Chrome Lighthouse PWA-audits
     
- Cache Storage debuggen
     
Je gaat tijd doorbrengen met staren naar gecachte requests, terwijl je je afvraagt waarom de werkelijkheid niet meer overeenkomt met productie. Dat is normaal.

3. Offline UX telt zwaarder dan offline kúnnen werken

Veel developers zijn geobsedeerd door “offline mode”, maar weinigen denken na over wat er gebeurt wanneer offline zich daadwerkelijk voordoet. De meeste apps hebben geen volledige offline-ondersteuning nodig; ze hebben nodig dat ze netjes falen. Dat is niet hetzelfde.
        
Soms hebben gebruikers alleen dit nodig:
       
- Eerder geladen content
     
- Concepten die bewaard blijven
      
- Een manier om het opnieuw te proberen
     
- Duidelijke statusindicatoren
     
De slechtste ervaring is doen alsof alles nog werkt, tot gebruikers ontdekken van niet. Een klein “Je bent offline — wijzigingen synchroniseren later” doet vaak meer voor de bruikbaarheid dan ingewikkelde synclogica. Hoe meer je product als een app aanvoelt, hoe voorspelbaarder het moet zijn.

4. Pushmeldingen klinken gaaf, tot je ze bouwt

Elke developer denkt vroeg of laat: “We moeten pushmeldingen toevoegen.” En dan komt de werkelijkheid langs.
     
Browserondersteuning verschilt. Permissies zijn fragiel. De UX wordt razendsnel irritant. Gebruikers wijzen prompts fanatiek af als de timing niet klopt.
     
En verandert je notificatiestrategie in willekeurige marketingspam, dan heb je gefeliciteerd precies de reden heruitgevonden waarom mensen meldingen uitzetten.
     
Toch zijn ze voor sommige producten oprecht waardevol:
     
- Herinneringen aan taken
      
- Statusupdates
     
- Operationele waarschuwingen
      
- Goedkeuringen in een workflow

- De Web Push API
      
- Firebase Cloud Messaging (FCM)
      
- Strategieën voor het vragen om notificatietoestemming
       
De techniek is te doen. Het productdenken is het lastige deel.

5. Over updates moet je anders gaan nadenken

Deze overvalt React-developers standaard. Op het web is deployen makkelijk. Code live zetten, pagina verversen, iedereen heeft de update. PWA's werken anders, want gecachte versies blijven hangen. Je hebt dus een strategie nodig:
     
- Moeten updates stilletjes gebeuren?
      
- Krijgen gebruikers een “Update beschikbaar”-melding?
     
- Mogen kritieke fixes een refresh afdwingen?
      
Slecht afgehandelde updates leveren bizarre bugs op, waarbij gebruikers zonder het te weten verschillende versies van de app draaien.

Supportgesprekken worden dan wonderlijk:
     
*“Kun je het reproduceren?”
“Nee.”
“Zit je op de laatste versie?”
“Ja.”*

Dat doen ze niet.

- De lifecycle van service workers beheren
     
- Updates op de achtergrond
    
- Patronen om een update aan te bieden
     
Dit klinkt saai tot het een release verpest.

Een PWA schroeft de verwachtingen op. Gebruikers vergelijken hem minder met websites en meer met apps. Trage opstarttijden, haperende transities en zware bundles vallen daardoor harder op. Gelukkig helpt moderne React-tooling je al een eind.
     
Ben je vertrouwd met Vite, code splitting, lazy loading, beeldoptimalisatie en performanceprofiling, dan heb je een voorsprong. Toch loont het om extra te letten op:
     
- De grootte van je initiële bundle
      
- Laden per route
       
- Geheugengebruik op mobiel
     
- Renderprestaties op minder krachtige apparaten
     
Op je MacBook valt het je waarschijnlijk niet op, maar oudere Android-toestellen leggen ongemakkelijke waarheden bloot.

Ben je al React-developer, dan is de leercurve kleiner dan mensen denken. Je hoeft niet van de ene op de andere dag mobile engineer te worden. Maar je wilt je wel thuis gaan voelen bij:
      
**De kernconcepten**
      
- Service workers
     
- Cachingstrategieën
     
- Installeerbaarheid
     
- Offline UX
     
- Updates afhandelen
      
**Handige tools**
      
- Workbox
      
- vite-plugin-pwa
      
- Lighthouse
      
- Chrome DevTools (Application-tab)
      
- Firebase Cloud Messaging
      
En misschien wel het allerbelangrijkste: ga de browser minder zien als iets dat documenten weergeeft, en meer als een runtime voor applicaties. Die omslag in denken is meestal de echte overgang. Het React-deel ken je waarschijnlijk al. De rare dingen beginnen pas zodra caching besluit dat hij het beter weet dan jij.

Nieuw Softwareproject / Modernisering

Turn-KeySoftwareDevelopment

ApplicatiebeheerenVernieuwing

Cloud&Databeveiliging

DeSoftwaremonteur(AI-onderhoud)

Gerelateerd Nieuws & Artikelen

Wat dertig minuten wachten per engineer per dag echt kost

DORA-metrics lezen als AI de helft van je commits schrijft

Een PWA bouwen in 2026: wat je als React-developer écht moet leren