07 sep 2025·8 min
Wat is jQuery en waarom zeggen mensen dat het vergeten is?
jQuery maakte JavaScript eenvoudiger met eenvoudige DOM-, event- en AJAX-tools. Lees wat het is, waarom het afnam en wanneer het vandaag nog steeds zinvol is.
jQuery maakte JavaScript eenvoudiger met eenvoudige DOM-, event- en AJAX-tools. Lees wat het is, waarom het afnam en wanneer het vandaag nog steeds zinvol is.
jQuery is een kleine JavaScript-bibliotheek die veel voorkomende taken op een webpagina makkelijker maakt—dingen zoals elementen selecteren, reageren op klikken, tekst veranderen, onderdelen van de pagina tonen/verbergen en verzoeken naar een server sturen.
Als je ooit code hebt gezien zoals $("button").click(...), dan is dat jQuery. De $ is alleen een snelkoppeling voor “zoek iets op de pagina en doe er iets mee.”
Deze gids is praktisch en niet-technisch: wat jQuery is, waarom het populair werd, waarom nieuwere projecten er minder vaak naar grijpen, en hoe je ermee omgaat als je site het nog gebruikt. Hij is bewust uitgebreider zodat we duidelijke voorbeelden en praktijkadvies kunnen geven in plaats van korte meningen.
Als mensen zeggen dat jQuery “vergeten” is, bedoelen ze meestal niet dat het verdwenen is. Ze bedoelen:
Dus het verhaal is niet “jQuery is dood.” Het is meer: jQuery verhuisde van de standaard tool voor front-end werk naar een legacy-dependency die je kunt erven—en af en toe nog steeds opzettelijk kiest.
Voor jQuery betekende front-end werk vaak hetzelfde kleine, vervelende codeblok steeds opnieuw schrijven—en het dan testen in meerdere browsers die zich verschillend gedroegen. Zelfs simpele doelen zoals “vind dit element”, “koppel een click-handler” of “stuur een request” konden uitgroeien tot een stapel speciale gevallen.
Veel vroege JavaScript ging minder over features bouwen en meer over worstelen met de omgeving. Je schreef code die in één browser werkte en voegde dan extra vertakkingen toe om het in een andere te laten werken. Teams hielden hun eigen interne “mini-bibliotheken” met helperfuncties om dagelijkse UI-wijzigingen te overleven.
Het resultaat: langzamer ontwikkelen, meer bugs en de constante angst dat een kleine wijziging een oudere browser zou breken waarop je gebruikers vertrouwden.
Browsers waren het niet eens over belangrijke details. DOM-selectiemethoden, eventafhandeling en zelfs hoe je elementmaten kreeg konden verschillen. Internet Explorer had bijvoorbeeld andere APIs voor events en XMLHTTP-requests, dus “standaard” code was niet altijd echt draagbaar.
Dat mattered omdat websites niet voor één browser werden gebouwd. Als je betaalpagina, navigatiemenu of modaal dialoog in een populaire browser faalde, was dat een echte zakelijke zorg.
jQuery werd belangrijk omdat het een consistente, vriendelijke API bood die die verschillen gladde.
Het maakte veelvoorkomende taken dramatisch eenvoudiger:
Net zo belangrijk was jQuery’s “write less, do more”-stijl die teams hielp sneller te leveren met minder browser-specifieke verrassingen—vooral in een tijd waarin moderne DOM-API’s niet zo capabel of breed ondersteund waren als nu.
jQuery’s echte kracht was niet dat het gloednieuwe ideeën introduceerde—maar dat het alledaagse browsertaken consistent en gemakkelijk maakte over verschillende browsers heen. Als je oudere front-end code leest, zie je meestal jQuery gebruikt voor vier dagelijkse klussen.
$-functie-idee)De $()-functie liet je elementen “pakken” met CSS-achtige selectors en vervolgens als groep bewerken.
In plaats van te worstelen met browserquirks en uitgebreide APIs, kon je alle items selecteren, een child-element vinden of naar een ouder bewegen met korte, ketenbare aanroepen.
jQuery maakte het eenvoudig om op gebruikersacties te reageren:
click voor knoppen en linkssubmit voor formulierenready om code uit te voeren wanneer de pagina geladen isHet zorgde ook voor consistentie in hoe browsers eventobjecten en bindingen behandelden, wat erg belangrijk was toen browserversie-ondersteuning ongelijk was.
Voor fetch() standaard werd, waren jQuery’s $.ajax(), $.get() en $.post() een eenvoudige manier om data van een server te vragen en de pagina bij te werken zonder te herladen.
Dit maakte patronen mogelijk die nu normaal aanvoelen—live search, "load more" knoppen, gedeeltelijke pagina-updates—met een enkele, vertrouwde API.
jQuery populariseerde snelle UI-aanrakingen zoals hide(), show(), fadeIn(), slideToggle() en animate(). Handig voor menu’s, notificaties en basistransities—vooral toen CSS-ondersteuning minder betrouwbaar was.
Gezamenlijk verklaren deze gemakken waarom legacy JavaScript-code vaak met $( begint en waarom jQuery zo lang de standaardtool bleef.
Veel van jQuery’s reputatie komt door hoeveel minder code het vaak kostte om alledaagse UI-taken te doen—vooral toen browserverschillen pijnlijk waren. Een snelle vergelijking maakt dat duidelijk.
jQuery
// Select a button and run code when it's clicked
$('#save').on('click', function (e) {
e.preventDefault();
$('.status').text('Saved!');
});
Modern (vanilla) JavaScript
// Select a button and run code when it's clicked
const saveButton = document.querySelector('#save');
const status = document.querySelector('.status');
saveButton?.addEventListener('click', (e) => {
e.preventDefault();
if (status) status.textContent = 'Saved!';
});
Op het eerste gezicht voelt de jQuery-versie “schoner”: één keten selecteert het element, koppelt een handler en werkt tekst bij. Die compactheid was een belangrijk verkoopargument.
Modern JavaScript is iets uitgebreider, maar ook explicieter:
querySelector en addEventListener vertellen precies wat er gebeurt.textContent is een standaard DOM-eigenschap (geen bibliotheeklaag ertussen).?.) en null-checks maken duidelijk wat er gebeurt als elementen niet bestaan.Het hangt van de context af. Als je een oudere codebase onderhoudt die overal jQuery gebruikt, is de jQuery-snipper misschien consistenter en sneller om mee te werken. Als je nieuwe code schrijft, zijn moderne DOM-API’s breed ondersteund, verminderen ze afhankelijkheden en zijn ze makkelijker te integreren met hedendaagse tooling en frameworks.
Lang was jQuery’s grootste voordeel voorspelbaarheid. Je kon op één manier elementen selecteren, events binden of een Ajax-request doen—en het werkte op de meeste plekken.
Met de jaren werden browsers gestandaardiseerd en verbeterd. Veel van de must-have gemakken die jQuery bundelde, zitten nu in JavaScript zelf, zodat je vaak geen extra bibliotheek meer nodig hebt om de basics te doen.
Moderne DOM-methoden dekken de meest voorkomende jQuery-patronen:
document.querySelector() / document.querySelectorAll() vervangen $(...) voor veel selecties.element.classList.add() / .remove() / .toggle() dekken klasse-manipulatie.element.addEventListener() verving jQuery’s event-wrapper voor de meeste use-cases.In plaats van jQuery-specifieke helpers te onthouden, kun je vertrouwen op standaard APIs die werken in moderne browsers.
Waar $.ajax() vroeger de standaard was, handelt fetch() nu veel dagelijkse requests met minder poespas, zeker in combinatie met JSON:
const res = await fetch('/api/items');
const data = await res.json();
Je moet nog steeds fouten en timeouts expliciet afhandelen, maar het kernidee—requests maken zonder een plugin—is nu native.
jQuery introduceerde veel mensen aan asynchrone code via callbacks en $.Deferred. Tegenwoordig maken Promises en async/await asynchrone stromen leesbaarder, en ES-modules maken duidelijker hoe code georganiseerd is.
Die combinatie—moderne DOM-API’s + fetch + moderne taalfeatures—verwijderde veel van de oorspronkelijke reden waarom teams standaard naar jQuery grepen.
jQuery groeide op in een tijd van “multi-page websites”: de server rendert HTML, de browser laadt een pagina en je plakt gedrag (click handlers, animaties, AJAX) bovenop bestaande markup.
Moderne front-end frameworks keerden dat model om. In plaats van pagina’s te verbeteren, genereert de app vaak het grootste deel van de UI in de browser en houdt die in sync met data.
React, Vue en Angular maakten populair om interfaces te bouwen uit componenten—kleine, herbruikbare delen die hun eigen markup, gedrag en state beheren.
In dit model wil het framework de bron van waarheid zijn voor wat op het scherm staat. Het houdt state bij, rendert delen van de UI opnieuw bij state-wijzigingen en verwacht dat je veranderingen declaratief uitdrukt (“als X waar is, toon Y”).
jQuery daarentegen moedigt imperatieve DOM-manipulatie aan (“vind dit element, verander de tekst, verberg het”). Dat kan conflicteren met de rendercyclus van een framework. Als je DOM-manipuleert die een component beheert, kan de volgende re-render je wijzigingen overschrijven—of je belandt in lastige inconsistenties.
Naarmate SPAs populair werden, adopteerden teams buildtools en bundlers (zoals Webpack, Rollup, Vite). In plaats van een paar script-tags te droppen, importeer je modules, bundle je alleen wat je gebruikt en optimaliseer je voor performance.
Die verschuiving maakte mensen ook gevoeliger voor afhankelijkheden en bundlegrootte. jQuery “voor het geval dat” toevoegen voelde minder natuurlijk toen elke kilobyte en elke update van derden deel uitmaakt van de pipeline.
Je kunt jQuery binnen een framework gebruiken, maar het wordt vaak een eiland met speciale gevallen—moeilijker te testen, lastiger te begrijpen en gevoeliger voor breuken tijdens refactors. Daardoor kiezen veel teams voor framework-native patronen in plaats van jQuery-stijl DOM-scripting.
jQuery zelf is niet “enorm”, maar het komt vaak met bagage. Veel projecten die op jQuery vertrouwen, verzamelen ook plugins (sliders, date pickers, modal libraries, validation helpers), elk voegt meer third-party code toe om te downloaden en te parsen. In de loop van de tijd kan een pagina meerdere overlappende utilities gaan verzenden—vooral als features snel werden toegevoegd en nooit herzien.
Meer JavaScript betekent meestal meer om te fetchen, parsen en uitvoeren voordat de pagina bruikbaar voelt. Dat is vooral merkbaar op mobiele apparaten, langzamere netwerken en oudere hardware. Zelfs als gebruikers uiteindelijk een vloeiende ervaring krijgen, kan de “time to usable” lijden wanneer de pagina wacht op extra scripts en hun dependencies.
Een veelvoorkomend patroon in langlopende sites is een “hybride” codebase: sommige features met jQuery, nieuwere delen met een framework (React, Vue, Angular) en een paar vanilla JavaScript-snippets. Die mix kan verwarrend worden:
Als meerdere stijlen naast elkaar bestaan, worden kleine wijzigingen riskanter. Een ontwikkelaar werkt een component bij, maar een oud jQuery-script grijpt nog steeds in dezelfde markup aan en veroorzaakt bugs die moeilijk reproduceerbaar zijn.
Teams stappen geleidelijk van jQuery af, niet omdat het “stopte met werken”, maar omdat moderne projecten optimaliseren voor kleinere bundles en duidelijke eigenaarschap van UI-gedrag. Naarmate sites groeien, maakt het verminderen van third-party code en standaardiseren op één aanpak het meestal makkelijker om performance te tunen, te debuggen en nieuwe ontwikkelaars in te werken.
jQuery werd niet alleen populair—het werd standaard. Jarenlang was het de makkelijkste manier om interactieve pagina’s betrouwbaar te maken in verschillende browsers, dus het belandde in talloze templates, snippets, tutorials en copy‑paste oplossingen.
Eenmaal zo wijdverspreid, werd jQuery moeilijk te vermijden: zelfs als een site maar één kleine feature gebruikte, laadde die vaak nog de hele bibliotheek omdat alles erop rekende.
Een belangrijke reden dat jQuery nog opduikt, is simpel: het succes maakte het overal in third-party code. Oudere UI-widgets, sliders, lightboxes, form validators en theme-scripts werden vaak als jQuery-plugins geschreven. Als een site afhankelijk is van zo’n component, kan het verwijderen van jQuery betekenen dat je die dependency moet herschrijven of vervangen—niet alleen een paar regels aanpassen.
WordPress is een grote bron van “legacy jQuery.” Veel thema’s en plugins—vooral die van jaren geleden—gebruiken jQuery voor front-end gedrag en historisch gezien vertrouwden WordPress admin-schermen er ook op. Zelfs wanneer nieuwere versies naar modern JavaScript bewegen, houdt de lange staart van bestaande extensies jQuery op veel installaties aanwezig.
Oudere sites geven vaak de voorkeur aan “breek niet wat werkt.” jQuery behouden kan de veiligste optie zijn wanneer:
Kortom: jQuery is niet altijd “vergeten”—het maakt vaak deel uit van de fundering waarop een site is gebouwd, en funderingen vervang je niet lichtvaardig.
jQuery is geen slecht stuk software—het is alleen minder noodzakelijk dan vroeger. Er zijn nog steeds reële situaties waarin het behouden (of zelfs toevoegen) van een beetje jQuery de meest praktische keuze is, vooral wanneer je optimaliseert voor tijd, compatibiliteit of stabiliteit in plaats van architecturale zuiverheid.
Als je vereisten oude browsers omvatten (vooral oudere IE-versies), kan jQuery nog steeds DOM-selectie, eventafhandeling en AJAX in eenvoudiger banen leiden dan native APIs zonder extra polyfills.
De vraag is altijd de kosten: legacy browserondersteuning betekent doorgaans dat je sowieso extra code zult leveren. In die context kan jQuery een acceptabel onderdeel van het compatibiliteitspakket zijn.
Als een site al rond jQuery is opgebouwd, zijn kleine UI-wijzigingen vaak sneller en veiliger als ze in dezelfde stijl gebeuren. Mixen van benaderingen kan verwarring brengen (twee patronen voor events, twee manieren om de DOM te manipuleren), wat onderhoud moeilijker maakt.
Een redelijke vuistregel: als je één of twee schermen aanraakt en de app verder stabiel is, is patchen met jQuery prima—vermijd alleen dat je jQuery-gebruik uitbreidt naar nieuwe “systemen” die je later moet terugdraaien.
Voor een eenvoudige marketingpagina of intern hulpmiddel—geen bundler, geen transpiler, geen component-framework—kan jQuery nog steeds een handige “single script tag” helper zijn. Vooral handig als je een paar interacties wilt (toggle menus, eenvoudige formuliergedragingen) en je liever geen buildpipeline introduceert.
Veel volwassen plugins (date pickers, tabellen, lightboxes) zijn gebouwd op jQuery. Als een oudere plugin bedrijfskritisch en stabiel is, kan het bewaren van jQuery als dependency de laagste risico-optie zijn.
Controleer voordat je beslist of er een onderhouden, niet-jQuery alternatief is—of dat upgraden van de plugin een breder herschrijfwerk vereist dan het project kan dragen.
Van jQuery af stappen gaat minder over een grote rewrite en meer over het verminderen van afhankelijkheid zonder gedrag te breken waarop mensen vertrouwen. De veiligste aanpak is incrementeel: houd pagina’s werkend terwijl je stukken vervangt.
Begin met drie praktische vragen:
Deze audit helpt je dingen te vermijden die je niet nodig hebt en spot “verborgen” afhankelijkheden zoals een plugin die stilletjes $.ajax() gebruikt.
De meeste teams boeken snelle winst door de eenvoudigste, meest voorkomende patronen te vervangen:
$(".card") → document.querySelectorAll(".card").addClass() / .removeClass() → classList.add() / classList.remove().on("click", ...) → addEventListener("click", ...)Doe dit in kleine PRs zodat het makkelijk te reviewen en terug te draaien is.
Als je $.ajax() gebruikt, migreer die calls naar fetch() (of een klein HTTP-hulpprogramma) endpoint voor endpoint. Houd de response-vormen hetzelfde zodat de rest van de UI niet meteen hoeft te veranderen.
// jQuery
$.ajax({ url: "/api/items", method: "GET" }).done(renderItems);
// Modern JS
fetch("/api/items")
.then(r => r.json())
.then(renderItems);
Voeg voordat je jQuery verwijdert dekking toe waar het telt: belangrijkste gebruikersstromen, formulierinzendingen en dynamische UI. Zelfs lichte checks (Cypress smoke tests of een QA-checklist) vangen regressies vroeg.
Lever veranderingen achter een feature-flag wanneer mogelijk en bevestig dat analytics/error-rates stabiel blijven. Als je extra veiligheid wilt tijdens refactors, helpt het gebruik van tooling die snapshots en rollback ondersteunt. Teams die legacy front-ends moderniseren prototypen soms vervangingen en gebruiken snapshot/rollback-workflows om te itereren zonder een "known-good" versie te verliezen.
Als je hulp wilt bij het organiseren van het algemene plan, zie dan de vergelijking in blog/jquery-vs-vanilla-js als baseline die je tijdens refactors kunt gebruiken.
Migreren van jQuery gaat meestal minder over "syntax vervangen" en meer over het ontwarren van jaren aan aannames. Hier zijn de valkuilen die teams vertragen—en hoe ze te vermijden.
Een volledige rewrite klinkt schoon, maar creëert vaak een lange lopende branche, veel regressies en druk om onafgemaakte dingen uit te rollen. Een veiligere aanpak is incrementeel: vervang één feature of pagina tegelijk, houd gedrag identiek en voeg tests toe rond de delen die je aanraakt.
Als je React/Vue/Svelte (of zelfs een lichtgewicht component-systeem) introduceert terwijl jQuery nog direct dezelfde DOM-nodes manipuleert, kun je een “UI-touwtrekken” krijgen: het framework rendert opnieuw en overschrijft jQuery-wijzigingen, terwijl jQuery elementen bijwerkt die het framework denkt te bezitten.
Vuistregel: kies een duidelijke scheidslijn. Ofwel:
Veel oudere code vertrouwt op gedelegeerde events zoals:
$(document).on('click', '.btn', handler)
Native DOM kan dit ook doen, maar matching en de verwachtingen rond this/event.target kunnen veranderen. Veelvoorkomende bugs zijn handlers die voor het verkeerde element vuren (door geneste icons/spans) of niet vuren voor dynamisch toegevoegde items omdat de listener aan de verkeerde ancestor was gekoppeld. Wanneer je gedelegeerde events vervangt, bevestig:
closest() is vaak nodig)jQuery UI-effecten en aangepaste animaties verstopten soms per ongeluk toegankelijkheidsproblemen—of veroorzaakten ze. Wanneer je fades, slides en toggles vervangt, controleer:
aria-expanded op disclosure-knoppen)prefers-reduced-motion)Deze valkuilen vroeg vangen maakt je migratie sneller en je UI betrouwbaarder—al voordat de laatste $() verdwijnt.
jQuery is niet “slecht.” Het loste echte problemen op—vooral toen browsers zich verschillend gedroegen en interactieve pagina’s bouwen veel repetitieve DOM-code betekende. Wat veranderde is dat je het tegenwoordig meestal niet meer nodig hebt voor nieuwe projecten.
Een paar krachten duwden het van “standaardkeuze” naar “legacy-dependency”:
Als je een oudere site onderhoudt, kan jQuery nog steeds een prima tool zijn—vooral voor kleine fixes, stabiele plugins of pagina’s die geen volledige rebuild rechtvaardigen. Als je nieuwe features bouwt, streef eerst naar native JavaScript en behoud jQuery alleen waar het duidelijk tijd bespaart.
Om verder te leren op een manier die aansluit op echt werk, ga door met:
Als je evalueert hoe je sneller kunt moderniseren, overweeg tools die helpen bij prototyping en gefaseerd uitrollen. Koder.ai kan hier nuttig zijn: je beschrijft het gedrag in chat, genereert een React-gebaseerde UI en een Go/PostgreSQL-backend wanneer nodig, en exporteert broncode zodra je klaar bent om te integreren met een bestaande codebase.
Als je tooling of supportopties evalueert, kun je ook opties bekijken via pricing
jQuery is een JavaScript-bibliotheek die veelvoorkomende browsertaken vereenvoudigt, zoals elementen selecteren, events afhandelen, Ajax-requests doen en basis-effecten (tonen/verbergen, fades, slides). Het kenmerkende patroon is het gebruik van de $()-functie om elementen te vinden en er methoden op te ketenen.
$ is gewoon een shortcutfunctie (meestal geleverd door jQuery) die elementen op de pagina vindt—vergelijkbaar met document.querySelectorAll()—en een jQuery-object teruggeeft waarop je methoden kunt ketenen.
Als je $() in oudere code ziet, betekent het vaak: “selecteer iets en doe er iets mee.”
Het werd populair omdat het inconsistente browsergedrag voorspelbaar maakte. In de beginjaren vergden simpele zaken zoals events, DOM-traversal en Ajax vaak browser-specifieke workarounds.
jQuery bood één voorspelbare API zodat teams sneller konden opleveren met minder cross-browser verrassingen.
Vooral omdat moderne browsers en JavaScript ingehaald zijn. Tegenwoordig kun je veel klassieke jQuery-taken vaak vervangen door ingebouwde features:
querySelector / querySelectorAll voor selectieNee. Veel bestaande sites gebruiken het nog en het blijft werken. “Legacy” betekent meestal dat het vaker voorkomt in oudere codebases dan in nieuwe.
De praktische vraag is of het de moeite waard is om jQuery te behouden, gezien performance, onderhoud en je huidige afhankelijkheden (vooral plugins).
Omdat het ingebakken zit in oudere ecosystemen—vooral thema’s en plugins. Een veelvoorkomend voorbeeld is WordPress, waar veel extensies historisch jQuery verwachtten.
Als je site afhankelijk is van een jQuery-only plugin (sliders, date pickers, lightboxes, validators), betekent het verwijderen van jQuery vaak dat je die plugin moet vervangen, niet alleen een paar regels herschrijven.
Ja, in een paar praktische situaties:
In deze gevallen kunnen stabiliteit en snelheid belangrijker zijn dan het verminderen van afhankelijkheden.
Begin incrementeel en meet effecten:
Eventdelegatie is een veelvoorkomende valkuil. jQuery-code zoals $(document).on('click', '.btn', handler) vertrouwt op jQuery’s matching en this-gedrag.
In native code heb je meestal nodig:
event.target.closest('.btn') om het bedoelde element te identificerenJa—effecten en DOM-wijzigingen kunnen per ongeluk toegankelijkheidsproblemen veroorzaken. Wanneer je hide()/show() of slide/fade-gedrag vervangt, controleer dan:
aria-expandedprefers-reduced-motion)Gedrag identiek houden is niet alleen visueel; het betreft ook interactie en toetsenbordstroom.
classListaddEventListener voor eventsfetch + async/await voor requestsDus nieuwe projecten hebben niet zo vaak meer een compatibiliteitslaag nodig voor de basistaken.
$.ajax()fetch()Kleine PRs en gefaseerde rollouts verminderen regressierisico.
Test gevallen met dynamische content (elementen toegevoegd na paginalaad).