Waarom maken meer ontwikkelaars geen gebruik van "het platform"?

Het argument is simpel: waarom zou je iets zelf bouwen in JavaScript, als de browser het voor je kan doen? Wat je ook bouwt, de kans is groot dat de prestaties en bruikbaarheid slechter zijn dan wanneer je gebruikmaakt van de functies die de browser standaard aanbiedt.

Toch denk ik dat het waardevol is om de andere kant te belichten, al is het maar om te begrijpen waar de "platform-sceptische" ontwikkelaars vandaan komen. Als "het platform gebruiken" zo'n overduidelijke keuze is, waarom moeten er dan zoveel mensen van overtuigd worden?

Historische context en gewenning

De meest voor de hand liggende reden is historisch. Lange tijd waren browsers bezig om de ecosystemen die bovenop hen draaiden bij te houden. Bibliotheken zoals jQuery vulden cruciale gaten terwijl browsers gelijkwaardige API's implementeerden. Zelfs dan moest je vaak wachten tot achterblijvers zoals IE6 uitstierven voordat je die functies daadwerkelijk kon gebruiken. Tegenwoordig zijn de meeste browsers evergreen (Safari is discutabel, hoewel ongeveer zeven updates per jaar niet slecht is), maar tot ongeveer de jaren 2020 hadden webontwikkelaars te maken met een zeer inconsistent web. In die omgeving was het zelf bouwen van oplossingen een verstandige keuze.

Een andere reden is gewenning. Wanneer je gewend bent om React-componenten op npm te zoeken, is dat waar je naartoe grijpt, ongeacht het probleem. Als je op npm zoekt naar "sticky positioning", is er geen pakket dat zegt: "gebruik gewoon CSS position: sticky, domoor."

Vaak vulden bibliotheken op npm bovendien een nuttige kloof tussen de ergonomie van een framework en het onderliggende platform. Het is interessant dat veel React-ontwikkelaars liever vasthouden aan JSX en React-idiomen — omdat directe DOM-API's "vies" voelden — maar perfect tevreden waren met het gebruik van low-level bibliotheken waarin directe DOM-manipulaties juist gebruikelijk zijn. Een bibliotheek voor virtuele lijsten kan bijvoorbeeld direct DOM-API's gebruiken voor maximale prestaties, terwijl het high-level primitives aanbiedt die een beginnende React-ontwikkelaar beter kan begrijpen. In zekere zin leidde het ecosysteem van React-componenten tot een natuurlijke arbeidsverdeling, waarbij experts onbekende platform-API's verpakten in een familiarere vorm.

De rol van documentatie

Een deel van dit effect werd gedreven door documentatie. Veel npm-pakketten hebben liefdevol gedetailleerde README's of websites met voorbeelden, tutorials en screenshots. Totdat MDN stevig verankerd raakte als de standaardplek voor webdocumentatie (met web.dev als de toekomstgerichte tak van Google), was de documentatie voor het webplatform versnipperd over blogs, StackOverflow en sites zoals CSS Tricks. Veel van deze sites adviseerden je bovendien simpelweg om een bekende bibliotheek zoals jQuery of GreenSock te gebruiken.

De vreugde van het zelf bouwen

Als het alleen zou gaan om bibliotheken van derden versus platform-API's, zou dat de antipathie tegen "gebruik het platform" niet volledig kunnen verklaren. Ontwikkelaars die lui zijn en gewoon een kant-en-klare oplossing willen, maakt waarschijnlijk niet uit of die oplossing van npm komt, uit de browser komt of gekopieerd is van een willekeurige GitHub Gist.

Er is echter een andere bron van weerstand. Voor een bepaald type ontwikkelaar is het simpelweg leuker om dingen zelf te bouwen. Vaak is de resulterende code makkelijker te doorgronden, vooral als je geen encyclopedische kennis van het webplatform hebt. En zodra je iets gebouwd hebt, kan er een soort "IKEA-effect" optreden: je wilt je eigen zelfgemaakte code onderhouden en verbeteren.

Stel je voor dat je een modaal dialoogvenster wilt bouwen. Je begrijpt visueel hoe dit moet werken: inhoud verschijnt op het scherm, de achtergrond blijft zichtbaar maar is gedeeltelijk afgeschermd, en misschien sluit het venster wanneer je buiten het dialoog klikt. Je grijpt dus naar position: absolute en z-index om het venster correct te positioneren. Dan merk je dat de achtergrond nog steeds scrolt, dus moet je de overflow op de body uitschakelen... En als je iets weet over toegankelijkheid, realiseer je je dat je de Esc-toets moet afhandelen, een focus trap moet bouwen en de focus moet terugsturen naar het element dat het dialoog startte, enzovoort.

Voor veel ontwikkelaars klinkt dit als een nachtmerrie. Maar voor anderen klinkt dit als puur plezier! Denk aan hoeveel je leert terwijl je dit bouwt. Je kunt er je eigen draai aan geven met animaties, thema's of een optionele sluitknop. Voor je het weet heb je een bibliotheek gebouwd die klaar is voor npm. Dat is veel leuker dan simpelweg <dialog> gebruiken en het daar bij laten.

Voor velen van ons was dit, voordat API's zoals <dialog> bestonden, de manier waarop we het webplatform leerden kennen. Veel van de mensen die nu pleiten voor "gebruik het platform" waren zelf ooit auteurs van polyfills, shims en bibliotheken. Ikzelf heb jaren gewerkt aan tooling voor IndexedDB, WebSQL en andere browser-storage API's voor PouchDB. Dit leidde ertoe dat ik me zelfverzekerd genoeg voelde om deel te nemen aan W3C-standaardisatievergaderingen en zelfs issues en pull requests te openen voor de IndexedDB-specificatie. Zonder de noodzaak om een gat in het platform te vullen, weet ik niet of ik de motivatie had бы gevonden om dit niveau van expertise te bereiken.

Onwetendheid en complexiteit

Natuurlijk is het zelf doen niet altijd een onverdeeld voordeel. Soms komt het voort uit pure onwetendheid. Op het webplatform specifiek denk ik dat de proliferatie van JavaScript-oplossingen voor problemen die beter met CSS opgelost hadden kunnen worden, komt doordat veel ontwikkelaars simpelweg de tijd niet namen om echt te begrijpen hoe CSS werkt.

Om eerlijk te zijn: CSS was historisch gezien moeilijk te begrijpen. Er is een reden waarom de site "CSS Tricks" heet. Concepten zoals de clear fix, floats en de min-width: 0 truc zijn verre van intuïtief. In plaats van het interne algoritme van CSS te proberen te begrijpen, is het vaak veel gemakkelijker om de imperatieve logica die je wilt te bedenken en dit in JavaScript uit te drukken. Bovendien had CSS jarenlang geen eenvoudige manier om veelvoorkomende patronen uit te drukken, zoals line clamping, het aanpassen van de grootte van een textarea of het verbergen van scrollbars. Natuurlijk bouwden ontwikkelaars dit zelf met de tools die ze al begrepen.

Een universeel platformprobleem

Dit fenomeen van het "vermijden van het platform" is niet beperkt tot het web. Het kan gelden voor elke ontwikkelaar die werkt op een platform dat hij of zij niet volledig begrijpt.

In mijn werk gebruiken we bijvoorbeeld ClickHouse voor het opslaan van analytische data. Op een gegeven moment hadden een collega en ik een meningsverschil over hoe we grote JSON-data in een kolom moesten opslaan: hij bouwde een systeem om de data te comprimeren vóór de opslag, terwijl ik de data in een aparte key-value store plaatste en alleen de sleutel in ClickHouse invoegde.

Beiden hadden we ongelijk. ClickHouse comprimeert data automatisch en, als kolomgebaseerde datastore, krijg je zelfs betere compressie over rijen heen als je ClickHouse het werk laat doen. De aparte key-value store was slechts een armzalige versie van wat een kolomgebaseerde SELECT al doet. Pas nadat ik de documentatie van ClickHouse grondig had gelezen en een benchmark had geschreven, realiseerde ik me dat we iets hadden gebouwd dat trager en onhandiger was dan wat het platform standaard bood. De parallellen met JavaScript en het webplatform waren onmiskenbaar.

Er is een reden waarom het stereotype van de ervaren senior engineer iemand is die de barokke, verstrengelde code van een junior kan vervangen door één enkele regel. Hoe meer je leert, hoe beter je in staat bent om je kennis van het gehele systeem end-to-end te gebruiken om de kleinst mogelijke bijdrage te leveren (en daarmee de onderhoudslast op lange termijn te verminderen).

De impact van AI op platformgebruik

Ik vraag me af hoe AI-coding dit fenomeen zal beïnvloeden. Ik heb hierover zowel een optimistische als een pessimistische visie:

• Optimistisch: Omdat LLM's een encyclopedische kennis hebben van het platform waarop je werkt, kunnen ze precies de juiste platform-API kiezen om de ervaring te leveren die de gebruiker in vaag Engels vraagt. Aangezien deze oplossing waarschijnlijk sneller en correcter is dan userland-code, zal de agent dit verkiezen na rigoureuze tests en benchmarks. Bovendien verdwijnt het "IKEA-effect" wanneer ontwikkelaars de code niet zelf schrijven.
• Pessimistisch: Omdat LLM's graag code dupliceren — bijvoorbeeld door bestaande helperfuncties te negeren en voor de zoveelste keer hun eigen versie te schrijven — zal de hoeveelheid custom, niet-platform-idiomatische code explosief toenemen. Ontwikkelaars zullen hun agents niet genoeg instrueren om alternatieven te testen en zullen simpelweg de eerste conceptversie van de agent committen. Omdat het altijd mogelijk is om meer "epicycli" toe te voegen, zullen agents blijven itereren op over-engineered oplossingen die nooit hadden mogen bestaan.

In mijn eigen gebruik van AI-coding heb ik beide fenomenen gezien. Ik hoop dat we, naarmate modellen en tooling verbeteren, meer richting de optimistische uitkomst bewegen, maar dat kan ik niet met zekerheid zeggen.

Conclusie

Dit zijn mijn uitgebreide en enigszins tegenstrijdige gedachten over "gebruik het platform". Als mantra hou ik ervan, omdat het succinct het gevoel vangt dat ik heb wanneer ik naar een overwerkte stapel spaghetticode kijk en denk hoe veel eleganter het zou zijn als de auteur de lagen eronder beter had begrepen.

Tegelijkertijd ben ik zelf die auteur geweest, en heb ik de vreugde gevoeld van het bouwen van zulke prachtige, rommelige code. Daarom denk ik dat het waardevol is om te begrijpen waar dergelijke ontwikkelaars vandaan komen. Om die reden ben ik ervan overtuigd dat we "gebruik het platform" zullen blijven horen, zolang er platforms bestaan.