jQuery 4.0: Wat de eerste grote release in tien jaar tijd werkelijk verandert

Home » Python » jQuery 4.0: Wat de eerste grote release in tien jaar tijd werkelijk verandert

Na bijna een decennium zonder grote update, jQuery 4.0 markeert een nieuw hoofdstuk. Voor een van de meest invloedrijke JavaScript-bibliotheken op het web. Deze release, die net na de 20e verjaardag van de onthulling van jQuery door John Resig verschijnt, draait niet zozeer om flitsende nieuwe trucjes, maar eerder om het verwijderen van ballast uit het verleden en het afstemmen van het project op de manier waarop we tegenwoordig daadwerkelijk voor browsers ontwikkelen.

In plaats van zichzelf opnieuw uit te vinden, jQuery 4 wil relevant blijven door de kern te moderniseren.Dit houdt in dat de ondersteuning voor verouderde browsers is stopgezet, er gebruik is gemaakt van ES-modules, de beveiliging is verbeterd door middel van Trusted Types en lang verouderde API's zijn opgeschoond. Het resultaat is een slankere bibliotheek die beter aansluit bij de huidige tools, zonder de website te verstoren voor het grote aantal sites dat ervan afhankelijk is.

Een belangrijke release waar tien jaar aan gewerkt is.

De overstap naar 4.0 is de eerste grote versie-update sinds de jQuery 3-serieDeze release volgt op een lange ontwikkelingscyclus met bètaversies en pre-releases die begin 2024 van start gingen. Het team omschreef het als de release waarin ze eindelijk wijzigingen hebben doorgevoerd die ze al jaren wilden, maar die ze niet via patches of kleine updates konden uitbrengen.

Achter het versienummer schuilt een bredere mijlpaal: jQuery bestaat nu al zo'n twintig jaar.Toen John Resig de bibliotheek in 2006 introduceerde, was het werken met de DOM in verschillende browsers zoals IE, Firefox en Safari foutgevoelig en omslachtig. jQuery werd al snel de standaardmethode om die inconsistenties te verhelpen, waardoor selectors zoals $("#myspan") Ze klinken veel toegankelijker dan de langdradige alternatieven van lokale auteurs.

Dat vroege succes heeft het web gevormd. Volgens langlopende technologieonderzoeken, jQuery is nog steeds te vinden op een groot aantal websites. die een JavaScript-bibliotheek declareren, zelfs nu nieuwere frameworks zoals React, Vue, Angular of Svelte de hoofdrol spelen in veel nieuwe projecten.

Gezien de wijdverbreide acceptatie hebben de beheerders herhaaldelijk benadrukt dat Ze kunnen het zich niet permitteren om per ongeluk bestaande pagina's te beschadigen.Vooral omdat veel websites jQuery rechtstreeks laden vanaf openbare CDN's. jQuery 4 bevindt zich daarom in een lastige positie: het introduceert ingrijpende wijzigingen, maar is zo ontworpen dat de meeste projecten met beperkte aanpassingen kunnen upgraden, geholpen door een officiële upgradehandleiding en een vernieuwde jQuery Migrate-plugin.

Einde van de weg voor IE10 en andere verouderde browsers.

Een van de meest in het oog springende beslissingen in deze release is dat Internet Explorer 10 en ouder worden niet langer ondersteund.Deze stap werd al jaren verwacht, maar jQuery 4 is de versie die eindelijk de knoop doorhakt. Dit weerspiegelt hoe weinig deze browsers worden gebruikt in moderne analyses en moedigt teams aan om... browsergebruik detecteren.

De afschrijving verloopt in fasen: IE 11 werkt nog steeds met jQuery 4.Maar het team heeft al aangegeven dat het in jQuery 5 zal worden verwijderd. Dat geeft organisaties met strikte beperkingen ten aanzien van verouderde technologieën wat ademruimte, terwijl het tegelijkertijd duidelijk maakt dat het IE-tijdperk ten einde loopt.

Rondom IE vinden er nog meer bezuinigingen plaats: Edge Legacy (pre-Chromium) verdwijnt uit de ondersteuningsmatrix.Samen met de oude Android-browser en oudere generaties van iOS en Firefox. Alleen de laatste paar versies van deze browsers, plus Firefox ESR, vallen nog onder de 3.x-lijn. Projecten die dergelijke omgevingen echt moeten ondersteunen, blijven naar verwachting binnen de 3.x-lijn.

Het opschonen van deze browserlijst is niet alleen Vereenvoudigt het testen in verschillende browsers.; Het verwijdert ook aanzienlijke delen van de compatibiliteitscode.Dat draagt ​​direct bij aan de kleinere bestandsgrootte van jQuery 4, vooral wanneer de specifieke vertakkingen voor Internet Explorer verwijderd zijn.

Beveiliging: Vertrouwde typen en strengere afstemming met CSP's

Naast browserondersteuning reageert jQuery 4 ook op moderne beveiligingsverwachtingen bij grootschalige productie-implementatiesVeel organisaties vertrouwen tegenwoordig sterk op Content Security Policy (CSP) om hun blootstelling aan cross-site scripting (XSS)-aanvallen te verminderen, en de interne werking van jQuery moest worden bijgewerkt om onder strengere regels te blijven functioneren.

De koptekstwijziging is ondersteuning voor vertrouwde typenWanneer een site beleid hanteert zoals require-trusted-types-for 'script', alleen waarden die zijn verpakt in specifieke vertrouwde typen (zoals TrustedHTML) kunnen worden geïnjecteerd in gevoelige DOM-sinks. Eerdere jQuery-versies konden deze beperkingen onbedoeld schenden in sommige API-paden, wat wrijving veroorzaakte voor teams die hun CSP wilden aanscherpen.

Met 4.0, HTML-inhoud die is verpakt als TrustedHTML kan nu worden doorgegeven aan de DOM-manipulatiemethoden van jQuery. zonder dat dit leidt tot schendingen van het beleid. De bibliotheek is gecontroleerd, zodat deze waar mogelijk samenwerkt met vertrouwde gegevenstypen in plaats van ze te bestrijden.

Een andere gerelateerde aanpassing heeft betrekking op het asynchroon laden van scripts. jQuery geeft nu de voorkeur aan het maken van standaarden <script> labels Voor veel asynchrone scriptverzoeken wordt nu gebruikgemaakt van inline-constructies in plaats van inline-constructies. Deze verschuiving helpt CSP-fouten te voorkomen in omgevingen die inline JavaScript verbieden, wat steeds vaker voorkomt in beveiligde implementaties.

Van AMD naar ES-modules en een nieuwe build-pipeline.

Onder de motorkap omarmt jQuery 4 ES-modules als primair moduleformaat.Daarmee wordt de oudere AMD-structuur, die lange tijd de basis vormde voor het bouwproces, achter zich gelaten. Dit brengt het project in lijn met het standaard modulesysteem waarop moderne JavaScript is gebaseerd.

In plaats van RequireJS gebruikt het project nu Rollup om de ES-modulebroncode te bundelenVoor teams die jQuery integreren in moderne toolchains, betekent dit dat de bibliotheek natuurlijker aansluit bij andere op ESM gebaseerde afhankelijkheden en direct kan worden gebruikt via <script type="module"> waar passend.

Ook de tests zijn aangepast: De modulegebaseerde versie wordt afzonderlijk gebruikt.Zodat problemen die specifiek zijn voor de ESM-build vroegtijdig kunnen worden opgespoord. Dit is met name relevant voor ontwikkelaars die slechts delen van jQuery in aangepaste bundels willen importeren, of die hun codebase standaardiseren op basis van ESM-semantiek.

De distributie is vanuit operationeel oogpunt niet drastisch veranderd. De nieuwe versie is beschikbaar via de officiële jQuery CDN en via npm., waarbij CDN's van derden het doorgaans na verloop van tijd oppakken. Voor bestaande CI-pipelines of implementatieprocessen betekent dit minimale wrijving bij de overstap van een eerdere 3.x-release naar de nieuwe builds.

Een lange lijst met verwijderde en verouderde API's

Waar eerdere, kleinere releases ontwikkelaars subtiel wegleidden van oude patronen, jQuery 4 verwijdert eindelijk veel API's die al jaren als verouderd waren gemarkeerd.Het doel is om gebruik te maken van de ingebouwde JavaScript-functies die elke ondersteunde browser al biedt.

Onder de te verwijderen voorzieningen bevinden zich bijvoorbeeld nutsvoorzieningen. jQuery.isArray, jQuery.parseJSON, jQuery.trim, jQuery.type, jQuery.now, jQuery.isNumeric, jQuery.isFunction, jQuery.isWindow, jQuery.camelCase, jQuery.nodeName, jQuery.cssNumberen jQuery.cssPropsDeze functies vulden oorspronkelijk hiaten op in inconsistente browserimplementaties, maar ze dupliceren grotendeels wat de taal zelf nu al biedt.

In praktijk, Er wordt verwacht dat codebases deze hulpprogramma's zullen vervangen door hun native equivalenten.: Array.isArray() in plaats van jQuery.isArray, JSON.parse() met de meeste jQuery.parseJSON vroeger was, String.prototype.trim() vervangen jQuery.trimen Date.now() besteld, jQuery.nowOnder andere. Door in deze richting te migreren, wordt code doorgaans beter overdraagbaar en minder afhankelijk van jQuery-specifiek gedrag.

Wat de interne componenten betreft, arraymethoden zoals push, sorten splice zijn verwijderd uit het jQuery-prototypeDit waren in feite interne hulpmiddelen die toevallig zichtbaar waren, en hun verwijdering maakt duidelijk dat ontwikkelaars jQuery-collecties anders moeten behandelen dan gewone arrays, ook al vertonen ze soms oppervlakkige overeenkomsten.

Al deze opschoning, in combinatie met het verwijderen van speciale code voor oudere versies van Internet Explorer, verkleint de omvang van de bibliotheek met meer dan 3 kilobyte in gzip-formaat.Voor websites die elke kilobyte belangrijk vinden, is dat een aanzienlijke besparing, vooral in combinatie met andere optimalisaties.

Standaard uitvoering, slanke uitvoering en kleinere bestandsgroottes

Bestandsgrootte is altijd al een onderwerp van discussie geweest rondom jQuery, en Versie 4 zet de trend naar een slankere kern voort.De geminificeerde standaardversie weegt nu iets minder dan 80 KB, vergeleken met ongeveer 88 KB voor jQuery 3.7.1.

De Slim Build is gericht op omgevingen die geen Ajax- of animatieondersteuning nodig hebben.Door die modules te verwijderen, daalt de grootte van de slanke variant van jQuery 4 nog verder, tot ongeveer 56 KB in het ene rapport en circa 19.5 KB gecomprimeerd in een ander, afhankelijk van welke statistieken en compressiedetails je bekijkt. Hoe dan ook, de richting is duidelijk: minder verouderde code, kleinere bundels.

Naast Ajax en animatie, de De slanke versie laat ook uitgestelde oproepen en terugbelverzoeken weg. in de nieuwe release. Aangezien native Promises nu goed worden ondersteund in alle doelbrowsers behalve IE11, had het team er vertrouwen in dat de meeste asynchrone patronen direct gebruik kunnen maken van de ingebouwde taalprimitieven.

Ontwikkelaars die de volledige API-interface prefereren, kunnen nog steeds kiezen voor de standaardversie, maar Projecten die de payload willen minimaliseren, hebben nu meer opties dan voorheen.Met steeds strengere prestatiebudgetten, vooral op mobiele apparaten, is de mogelijkheid om voor een uitgeklede variant te kiezen een praktisch voordeel.

Focus- en blur-gebeurtenissen volgen nu de W3C-specificatie.

Een van de subtielere, maar toch impactvolle gedragsveranderingen in jQuery 4 betreft... focus- en blur-gebeurtenissen op gebruikersinterface-elementenHistorisch gezien verschilden browsers van mening over de exacte volgorde waarin deze gebeurtenissen plaatsvonden, wat leidde tot moeilijk te traceren inconsistenties.

Om daarmee om te gaan, Eerdere jQuery-versies overschreven de native volgorde van gebeurtenissen. Het doel was om een ​​uniforme volgorde te bieden, zelfs als dat betekende dat er werd afgeweken van de zich ontwikkelende standaarden. Ontwikkelaars bouwden code op basis van die aannames, vaak zonder zich te realiseren dat het gedrag afweek van wat browsers geleidelijk aan standaardiseerden.

Nu de W3C-specificatie een consistente volgorde definieert voor focus, focusin, focusout en blurModerne browsers zijn grotendeels op dat model overgestapt. Als reactie daarop verwijdert jQuery 4 de oude override-logica en laat de oorspronkelijke volgorde van gebeurtenissen prevaleren in alle ondersteunde browsers, conform de huidige specificatie.

Het voordeel is dat Het gedrag wordt voorspelbaarder binnen het ecosysteem.Het nadeel is dat code die afhankelijk was van de eerdere volgorde van jQuery zich nu anders kan gedragen, waardoor er mogelijk onverwachte problemen ontstaan ​​in formulieren of complexe UI-interacties. Dit is een van de gebieden waar het uitvoeren van tests en het gebruik van de bijgewerkte jQuery Migrate-plugin tijdens upgrades bijzonder nuttig kan zijn.

Een gestroomlijndere bibliotheek, maar niet iedereen is het eens over haar rol.

Zoals bij elke technologie die lang meegaat, De meningen over de plaats van jQuery in 2026 zijn sterk verdeeld.Voor sommige ontwikkelaars is de conclusie simpel: als je een gloednieuwe webapplicatie ontwikkelt die gericht is op moderne browsers, lijkt er weinig reden te zijn om jQuery überhaupt te introduceren.

Critici wijzen vaak op prestatie- en afhankelijkheidsproblemenNative JavaScript is doorgaans sneller en voorkomt het toevoegen van tientallen kilobytes aan bibliotheekcode. Oudere jQuery-versies blijven bovendien vaak ongewijzigd op productiesites draaien, waarbij een aanzienlijk deel van het web naar verluidt nog steeds 2.x-versies van tien jaar oud gebruikt.

Aan de andere kant van het debat stellen veel professionals dat jQuery blijft een efficiënt en praktisch hulpmiddel voor dagelijks gebruik.Hoewel frameworks zoals React of Vue de boventoon voeren bij grote single-page applicaties, is jQuery vaak een eenvoudigere keuze voor incrementele verbeteringen, klassieke multi-page websites of snelle prototypes waarbij het opzetten van een volledige componentenpipeline overbodig aanvoelt.

Er zijn nog steeds ontwikkelaars die jQuery omschrijven als Een van de weinige JavaScript-bibliotheken die consistent prettig aanvoelt in gebruik.Vooral handig voor DOM-manipulatie en gebeurtenisafhandeling. De beknopte syntaxis, de mogelijkheid om methoden aan elkaar te koppelen en de beproefde conventies kunnen overbodige code verminderen en kleine scripts leesbaar houden.

Dat contrast in perspectieven betekent dat jQuery 4 waarschijnlijk op verschillende manieren geïnterpreteerd zal worden: Sommigen zien het als een elegante modernisering van een verouderde tool, anderen als een release met minimaal onderhoud voor een tijdperk dat ten einde loopt.In de praktijk blijven veel productielocaties er gebruik van maken, ongeacht of het in nieuwe projecttemplates wordt opgenomen.

Praktisch gebruik: wanneer jQuery nog steeds tijd bespaart

Naast abstracte argumenten laten verhalen uit de dagelijkse ontwikkelingspraktijk zien hoe jQuery kan bepaalde problemen nog steeds oplossen met zeer weinig code.Een voorbeeld hiervan is het bouwen van geanimeerde, schakelbare formuliervelden, waarbij sommige invoervelden alleen verschijnen wanneer andere zijn geselecteerd of aangevinkt.

In dat geval, Een ontwikkelaar probeerde aanvankelijk het gewenste gedrag te creëren met pure JavaScript.Het script moest meerdere eventlisteners, CSS-transities en timingproblemen tegelijk beheren. Na verschillende pogingen was het script uitgegroeid tot meer dan vijftig regels en kampte het nog steeds met racecondities, waarbij animaties elkaar tegenwerkten of in de verkeerde volgorde werden uitgevoerd.

Uiteindelijk won de frustratie het en jQuery 4 is toegevoegd als afhankelijkheid.Door gebruik te maken van de mogelijkheden voor gebeurtenisafhandeling en animatie, werd hetzelfde effect in slechts enkele regels code bereikt. De afweging was duidelijk: een extra bibliotheek van ongeveer 80 KB in ruil voor een veel eenvoudigere implementatie en de mogelijkheid om verder te gaan met andere functionaliteiten.

Scenario's zoals deze laten zien waarom Het aloude motto van de bibliotheek, "schrijf minder, doe meer", vindt nog steeds weerklank bij sommige teams.Zelfs in een tijdperk van native API's en geavanceerde frameworks zijn er momenten waarop een klein script, aangevuld met jQuery, sneller te bouwen en gemakkelijker te onderhouden is dan een volledig op maat gemaakte oplossing.

Dat betekent natuurlijk niet dat elk project baat heeft bij het gebruik van jQuery. Moderne JavaScript- en DOM-API's zijn consistenter dan voorheen.De HTML5- en ECMAScript-standaarden hebben de problemen met compatibiliteit tussen browsers verminderd, en voor veel single-page applicaties is een framework of zelfs helemaal geen bibliotheek wellicht een betere oplossing. Het gaat er niet zozeer om dat jQuery universeel noodzakelijk is, maar eerder dat het een nuttige optie blijft wanneer het probleem en de beperkingen overeenkomen.

Van essentiële abstractie tot standaardbibliotheekrol

Om te begrijpen waarom jQuery 4 zich richt op het stroomlijnen in plaats van zichzelf opnieuw uit te vinden, is het handig om het volgende te onthouden: Hoe anders het landschap eruitzag toen de bibliotheek er stond.Twee decennia geleden verschilden browsers vaak in hun interpretatie van JavaScript en DOM-gedrag, waardoor zelfs de meest basale interacties kwetsbaar aanvoelden.

In die omgeving, jQuery was eigenlijk geen optie. Voor veel teams was het een waardevolle aanvulling. Het bundelde Ajax-aanroepen, DOM-selectie, gebeurtenisafhandeling en animatie in een consistente API, waardoor ontwikkelaars erop konden vertrouwen dat code zich op dezelfde manier zou gedragen in IE, Firefox, Safari en later Chrome. Deze consistentie was cruciaal in een tijd waarin Microsoft vaak zijn eigen ideeën nastreefde met Internet Explorer en verwachtte dat anderen dat voorbeeld zouden volgen.

Sindsdien zijn standaardisatieorganisaties en browserleveranciers tot overeenstemming gekomen over HTML5, moderne ECMAScript-versies en een veel betere afstemming tussen browsersDe engine van Chrome en de daarvan afgeleide engines domineren de markt, en de basisfunctionaliteiten van browsers liggen veel hoger dan toen jQuery zich voor het eerst verspreidde onder ontwikkelaars.

Het resultaat is dat jQuery tegenwoordig minder te maken heeft met het omzeilen van incompatibiliteiten en meer met... fungeert als een handige, vertrouwde "standaardbibliotheek" bovenop JavaScriptDe manier waarop functies aan elkaar worden gekoppeld en de beknopte uitdrukkingen stimuleren een ontspannen, bijna functionele manier om DOM-intensieve code te structureren, ook al is de onderliggende taal niet puur functioneel.

Voor ontwikkelaars die alleen maar moderne tools kennen, De omvang van de invloed van jQuery wordt soms gemakkelijk over het hoofd gezien.Veel patronen die door de bibliotheek zijn geïntroduceerd of populair gemaakt, zijn weer opgenomen in de taal en de DOM API's zelf. In die zin probeert jQuery 4 niet zozeer verloren terrein terug te winnen, maar de bibliotheek juist in lijn te houden met het ecosysteem dat eromheen is ontstaan.

De wijzigingen in jQuery 4.0.0 – van het laten vallen van IE10 tot het gebruik van ES-modules, Trusted Types en een slankere set API's – weerspiegelen in hun geheel het volgende: een project dat bewust evolueert zonder de miljoenen websites die er nog steeds van afhankelijk zijn in de steek te laten.Deze release is niet bedoeld om rechtstreeks te concurreren met moderne frameworks, maar biedt teams die jQuery blijven gebruiken wel een versie die goed aansluit bij de huidige browser- en toolingomgeving, terwijl de mogelijkheid tot geleidelijke migratie openblijft waar dat zinvol is.