Wat is jQuery en waarom zeggen mensen dat het vergeten is?

jQuery in één minuut

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.”

Wat dit artikel behandelt

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.

Wat mensen bedoelen met “vergeten”

Als mensen zeggen dat jQuery “vergeten” is, bedoelen ze meestal niet dat het verdwenen is. Ze bedoelen:

• Het wordt minder gebruikt in nieuwe projecten, omdat moderne browsers veel functies ondersteunen die jQuery vroeger bood.
• Het is nog steeds gebruikelijk in oudere sites (en in sommige plugins, thema’s en admin panels) omdat het werkt, bekend is en vervangen tijd kost.

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.

Waarom jQuery zo belangrijk was

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.

Hoe front-end ontwikkeling voelde vóór jQuery

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.

Browserverschillen en waarom ze telden

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.

De kloof die jQuery vulde voor alledaagse taken

jQuery werd belangrijk omdat het een consistente, vriendelijke API bood die die verschillen gladde.

Het maakte veelvoorkomende taken dramatisch eenvoudiger:

• DOM-elementen selecteren en manipuleren met CSS-achtige selectors
• Events afhandelen op een cross-browser manier
• Animaties en effecten zonder zelf timers te schrijven
• Ajax-requests met een enkele, voorspelbare interface

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.

Kernzaken waarin jQuery helpt

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.

1) DOM-selectie en traversing (het $-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.

2) Events: click/submit/ready-patronen

jQuery maakte het eenvoudig om op gebruikersacties te reageren:

• click voor knoppen en links
• submit voor formulieren
• ready om code uit te voeren wanneer de pagina geladen is

Het zorgde ook voor consistentie in hoe browsers eventobjecten en bindingen behandelden, wat erg belangrijk was toen browserversie-ondersteuning ongelijk was.

3) AJAX-basics (gegevens laden zonder herladen)

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.

4) Effects/animaties en simpele UI-helpers

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.

Een simpel voorbeeld: jQuery vs modern JavaScript

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.

Een element selecteren en een klik afhandelen

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!';
});

Leesbaarheid: minder regels vs duidelijkere APIs

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).
• Optionele chaining (?.) en null-checks maken duidelijk wat er gebeurt als elementen niet bestaan.

Welke is “beter”?

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.

Native JavaScript haalde in

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.

DOM-API’s werden eenvoudiger en consistenter

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.

Netwerkverzoeken verhuisden naar fetch

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.

Betere structuur met Promises, async/await en modules

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.

Frameworks veranderden hoe UIs worden gebouwd

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.

Single-page apps en component-gebaseerde UI

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.

Buildtools en bundlers veranderden hoe code wordt geleverd

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.

Waarom jQuery ongemakkelijk kan aanvoelen in component-apps

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.

Bundlegrootte en onderhoudsdruk

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.

Grotere downloads, meer werk voor de browser

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.

De verborgen kosten: gemengde stijlen en mentale overhead

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:

• Twee manieren om elementen te selecteren en de DOM bij te werken
• Verschillende eventmodellen en lifecycle-aannames
• Concurrerende oplossingen voor state (DOM als state vs component state)

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.

Onderhoudsdruk loopt op

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.

Waarom je jQuery nog steeds op oudere sites ziet

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.

Het zit ingebakken in oudere plugins en thema’s

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 erfde het (en hield het)

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.

Legacy-systemen geven prioriteit aan stabiliteit boven verandering

Oudere sites geven vaak de voorkeur aan “breek niet wat werkt.” jQuery behouden kan de veiligste optie zijn wanneer:

• de site stabiel en omzet-kritisch is
• tijd beperkt is en regressietesten duur zijn
• de codebase jaren aan kleine fixes bevat die niemand opnieuw wil auditen

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.

Wanneer jQuery nog steeds zinvol is

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.

Je moet legacy browsers ondersteunen

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.

Je hebt snelle fixes nodig in een bestaande jQuery-codebase

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.

Kleine sites zonder buildstap

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.

Je gebruikt een oudere plugin die ervan afhankelijk is

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.

Hoe veilig van jQuery af te stappen

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.

1) Audit wat je eigenlijk gebruikt

Begin met drie praktische vragen:

• Welke pagina’s laden jQuery?
• Welke plugins zijn ervan afhankelijk (sliders, date pickers, validatie, enz.)?
• Welke jQuery-features staan in je codebase (DOM-selectie, eventafhandeling, AJAX, animaties)?

Deze audit helpt je dingen te vermijden die je niet nodig hebt en spot “verborgen” afhankelijkheden zoals een plugin die stilletjes $.ajax() gebruikt.

2) Vervang eerst laaghangend fruit

De meeste teams boeken snelle winst door de eenvoudigste, meest voorkomende patronen te vervangen:

• Selectoren: $(".card") → document.querySelectorAll(".card")
• Klasses: .addClass() / .removeClass() → classList.add() / classList.remove()
• Events: .on("click", ...) → addEventListener("click", ...)

Doe dit in kleine PRs zodat het makkelijk te reviewen en terug te draaien is.

3) Plan je AJAX-transitie

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);

4) Verminder risico met tests en gefaseerde uitrol

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.

Veelvoorkomende migratievalkuilen

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.

Alles in één keer willen herschrijven

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.

jQuery mixen met een component-framework in hetzelfde UI-gebied

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:

• Houd jQuery binnen een legacy-container en mount het framework elders, of
• Migreer die hele widget als één eenheid voordat je nieuwe gedragingen toevoegt.

Verschillen in eventdelegatie

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:

• Welk element als de “geklikte knop” moet gelden (closest() is vaak nodig)
• Of events eerder genamespace'd waren (jQuery ondersteunt dit; native vereist een andere strategie)

Toegankelijkheidsregressies bij het vervangen van effecten

jQuery UI-effecten en aangepaste animaties verstopten soms per ongeluk toegankelijkheidsproblemen—of veroorzaakten ze. Wanneer je fades, slides en toggles vervangt, controleer:

• Focusmanagement (waar de toetsenbordfocus na openen/sluiten terechtkomt)
• ARIA-staten (bijv. aria-expanded op disclosure-knoppen)
• Reduced motion-voorkeuren (prefers-reduced-motion)

Deze valkuilen vroeg vangen maakt je migratie sneller en je UI betrouwbaarder—al voordat de laatste $() verdwijnt.

Belangrijkste conclusies en vervolgstappen

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.

Waarom jQuery afnam

Een paar krachten duwden het van “standaardkeuze” naar “legacy-dependency”:

• Moderne DOM-API’s verbeterden: selecteren, klassen aanpassen en events afhandelen werden eenvoudig in native JavaScript.
• Browserconsistentie nam toe: minder quirks betekende minder waarde van een compatibiliteitslaag.
• Frameworks veranderden verwachtingen: React/Vue/Angular moedigden component-based UIs en state-gedreven rendering aan, waar directe DOM-manipulatie minder centraal is.
• Performance en onderhoudsdruk: teams begonnen meer te letten op bundlegrootte, dependency-updates en het verminderen van “mystery code” in grote apps.

Praktische vervolgstappen

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:

• DOM-grondbeginselen en veelvoorkomende patronen: blog/vanilla-js-dom-basics
• Oude AJAX-patronen vervangen door moderne requests: blog/fetch-api-beginners

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