jQuery 4.0: Hvad den første store udgivelse i et årti virkelig ændrer

Hjem » Python » jQuery 4.0: Hvad den første store udgivelse i et årti virkelig ændrer

Efter næsten et årti uden en større opdatering, jQuery 4.0 markerer et nyt kapitel for et af de mest indflydelsesrige JavaScript-biblioteker på nettet. Denne udgivelse, der er timet til at lande lige efter 20-årsdagen for John Resigs afsløring af jQuery, handler ikke så meget om prangende nye tricks, som den handler om at fjerne gammel bagage og tilpasse projektet til, hvordan vi rent faktisk bygger til browsere i dag.

I stedet for at genopfinde sig selv, jQuery 4 sigter mod at forblive relevant ved at modernisere sin kerne: fjernelse af understøttelse af forældede browsere, omfavnelse af ES-moduler, forbedring af sikkerheden gennem Trusted Types og oprydning af længe forældede API'er. Resultatet er et mere slankt bibliotek, der passer mere naturligt ind i nuværende værktøjer, samtidig med at det stadig forsøger ikke at "bryde nettet" for det enorme antal websteder, der er afhængige af det.

En større udgivelse, der har været et årti undervejs

Springet til 4.0 er den første store versionsopdatering siden jQuery 3-serien, der ankommer efter en lang udviklingscyklus med betaversioner og pre-udgivelser, der startede i starten af ​​2024. Holdet har beskrevet det som udgivelsen, hvor de endelig implementerede ændringer, de havde ønsket i årevis, men ikke kunne levere i form af patches eller mindre opdateringer.

Bag versionsnummeret gemmer sig en bredere milepæl: jQuery har nu eksisteret i omkring tyve årDa John Resig først introducerede biblioteket i 2006, var det fejlbehæftet og kedeligt at arbejde med DOM på tværs af browsere som IE, Firefox og Safari. jQuery blev hurtigt den facto måde at udjævne disse uoverensstemmelser på, hvilket gjorde selektorer som $("#myspan") føles langt mere tilgængelige end ordrige, indfødte alternativer.

Den tidlige succes formede internettet. Ifølge langvarige teknologiundersøgelser, jQuery er stadig til stede på et stort flertal af websteder der deklarerer et JavaScript-bibliotek, selvom nyere frameworks som React, Vue, Angular eller Svelte har taget en central plads i mange nye projekter.

Med en så udbredt anvendelse har vedligeholderne gentagne gange understreget, at de kan ikke risikere at ødelægge eksisterende sider tilfældigt, især fordi mange websteder indlæser jQuery direkte fra offentlige CDN'er. jQuery 4 følger derfor en hårfin grænse: den introducerer breaking ændringer, men er designet, så de fleste projekter kan opgraderes med begrænsede ændringer, hjulpet af en officiel opgraderingsguide og et opdateret jQuery Migrate-plugin.

Vejens ende for IE10 og andre ældre browsere

En af de mest synlige beslutninger i denne udgivelse er, at Internet Explorer 10 og ældre understøttes ikke længereDette skridt har været forventet i årevis, men jQuery 4 er den version, der endelig sætter en stopper for det, hvilket afspejler hvor lidt brug disse browsere ser i moderne analyser og opfordrer teams til at registrere browserbrug.

Afskrivningshistorien er faset: IE 11 fungerer stadig med jQuery 4, men teamet har allerede indikeret, at det vil blive droppet i jQuery 5. Det giver organisationer med strenge restriktioner for ældre versioner noget pusterum, samtidig med at det tydeligt gør det, at IE-æraen er ved at være slut.

Omkring IE er der yderligere nedskæringer: Edge Legacy (før Chromium) forsvinder fra supportmatricen, sammen med den gamle Android-browser og ældre generationer af iOS og Firefox. Kun de sidste par versioner af disse browsere, plus Firefox ESR, er fortsat inkluderet. Projekter, der virkelig skal understøtte sådanne miljøer, forventes at forblive på 3.x-linjen.

Beskæring af denne browserliste er ikke kun forenkler testning på tværs af browsere; det fjerner også betydelige bidder af kompatibilitetskodeDet bidrager direkte til den mindre filstørrelse i jQuery 4, især når de specifikke grene i Internet Explorer er væk.

Sikkerhed: Pålidelige typer og strengere CSP-tilpasning

Udover browserunderstøttelse reagerer jQuery 4 også på Moderne sikkerhedsforventninger i store produktionsinstallationerMange organisationer er nu i høj grad afhængige af Content Security Policy (CSP) for at reducere eksponeringen for cross-site scripting (XSS)-angreb, og jQuerys interne funktioner havde brug for opdateringer for at opføre sig korrekt under strengere regler.

Ændringen af ​​overskriften er understøttelse af betroede typerNår et websted håndhæver politikker som f.eks. require-trusted-types-for 'script', kun værdier indpakket i specifikke betroede typer (som f.eks. TrustedHTML) kan blive injiceret i følsomme DOM-sinks. Tidligere jQuery-versioner kunne utilsigtet overtræde disse begrænsninger i nogle API-stier, hvilket skabte friktion for teams, der forsøgte at stramme deres CSP.

Med 4.0, HTML-indhold pakket som TrustedHTML kan nu overføres til jQuerys DOM-manipulationsmetoder uden at udløse politikovertrædelser. Biblioteket er blevet revideret, så det, hvor det er muligt, arbejder med betroede typer i stedet for at bekæmpe dem.

En anden relateret justering påvirker indlæsning af asynkron script. jQuery foretrækker nu at oprette standard <script> tags for mange asynkrone scriptanmodninger i stedet for at stole på inline-konstruktioner. Dette skift hjælper med at undgå CSP-fejl i opsætninger, der forbyder inline JavaScript, hvilket er stadig mere almindeligt i hærdede implementeringer.

Fra AMD til ES-moduler og en ny build-pipeline

Under motorhjelmen omfavner jQuery 4 ES-moduler som det primære modulformatog efterlader den ældre AMD-struktur, der længe drev dens byggekæde. Dette justerer projektet med det standardmodulsystem, som moderne JavaScript er afhængig af.

I stedet for RequireJS bruger projektet nu Opsamling for at bundte ES-modulkildenFor teams, der integrerer jQuery i moderne værktøjskæder, betyder det, at biblioteket passer mere naturligt sammen med andre ESM-baserede afhængigheder og kan forbruges direkte via <script type="module"> Hvor det er passende.

Testene er også blevet tilpasset: Den modulbaserede version udføres alene, så problemer specifikke for ESM-buildet kan opdages tidligt. Dette er især relevant for udviklere, der kun ønsker at importere dele af jQuery i brugerdefinerede bundter, eller som standardiserer deres kodebase omkring ESM-semantik.

Distributionen har ikke ændret sig dramatisk fra et operationelt perspektiv. Den nye version er tilgængelig via det officielle jQuery CDN og via npm, hvor tredjeparts-CDN'er typisk tager det over tid. For eksisterende CI-pipelines eller implementeringsprocesser betyder det minimal friktion ved skift fra en tidligere 3.x-udgivelse til de nye builds.

En lang liste over fjernede og udfasede API'er

Hvor tidligere mindre udgivelser blidt skubbede udviklere væk fra gamle mønstre, jQuery 4 fjerner endelig mange API'er, der har været markeret som forældede i årevis.Målet er at læne sig op ad indbyggede JavaScript-funktioner, som alle understøttede browsere allerede tilbyder.

Blandt flytningerne er forsyningsvirksomheder som f.eks. jQuery.isArray, jQuery.parseJSON, jQuery.trim, jQuery.type, jQuery.now, jQuery.isNumeric, jQuery.isFunction, jQuery.isWindow, jQuery.camelCase, jQuery.nodeName, jQuery.cssNumberog jQuery.cssPropsDisse funktioner udfyldte oprindeligt huller i inkonsistente browserimplementeringer, men de duplikerer i vid udstrækning, hvad sproget selv nu tilbyder.

I praksis, Kodebaser forventes at bytte disse hjælpere ud med deres oprindelige ækvivalenter.: Array.isArray() i stedet for jQuery.isArray, JSON.parse() hvor jQuery.parseJSON plejede at være, String.prototype.trim() udskiftning jQuery.trimog Date.now() forum jQuery.now, blandt andre. Migrering i denne retning har en tendens til at gøre kode mere bærbar og mindre bundet til jQuery-specifik adfærd.

På den indre side, array-metoder såsom push, sortog splice er blevet fjernet fra jQuery-prototypenDisse var reelt interne hjælpere, der tilfældigvis blev eksponeret, og deres fjernelse tydeliggør, at udviklere bør behandle jQuery-samlinger anderledes end almindelige arrays, selvom de nogle gange deler overfladiske ligheder.

Al denne oprydning, kombineret med at fjerne kode med specialtilfælde fra ældre versioner af Internet Explorer, reducerer bibliotekets fodaftryk med mere end 3 kilobyte i gzip-formatFor websteder, der værdsætter hver en kilobyte, er det en ikke-triviel besparelse, især når den kombineres med andre optimeringer.

Standard build, slim build og filstørrelsesreduktioner

Filstørrelse har altid været en del af samtalen omkring jQuery, og Version 4 fortsætter tendensen mod en slankere kerneDen minimerede standardversion vejer nu lige under 80 KB, sammenlignet med cirka 88 KB for jQuery 3.7.1.

Slim build er rettet mod miljøer, der ikke kræver Ajax- eller animationsunderstøttelseVed at fjerne disse moduler falder jQuery 4's slanke variant yderligere og lander på omkring 56 KB i én rapport og cirka 19.5 KB gzippet i en anden, afhængigt af hvilke metrikker og komprimeringsdetaljer man ser på. Under alle omstændigheder er retningen klar: mindre ældre versioner, mindre bundter.

Ud over Ajax og animation, Slim build udelader også udskudte kald og tilbagekald i den nye udgivelse. I betragtning af at native Promises nu er velunderstøttet på tværs af alle målbrowsere undtagen IE11, følte teamet sig sikre på, at de fleste asynkrone mønstre kan stole direkte på de indbyggede sprogprimitiver.

Udviklere, der foretrækker den fulde API-overflade, kan stadig vælge standardversionen, men Projekter, der ønsker at minimere nyttelast, har flere muligheder end førMed stadigt strengere præstationsbudgetter, især på mobil, er muligheden for at vælge en trimmet variant en praktisk fordel.

Fokus- og sløringshændelser følger nu W3C-specifikationen

En af de mere subtile, men betydningsfulde adfærdsændringer i jQuery 4 involverer fokus- og sløringshændelser på brugergrænsefladeelementerHistorisk set var browsere uenige om den præcise rækkefølge, hvori disse hændelser blev udløst, hvilket førte til uoverensstemmelser, der var svært at spore.

For at klare det, Tidligere jQuery-versioner tilsidesatte native event-rækkefølge at skabe en ensartet sekvens, selvom det betød at afvige fra udviklende standarder. Udviklere byggede kode oven på disse antagelser, ofte uden at indse, at adfærden afveg fra det, browsere gradvist standardiserede.

Nu hvor W3C-specifikationen definerer en ensartet rækkefølge for focus, focusin, focusout og blur, moderne browsere har for det meste konvergeret omkring den model. Som svar fjerner jQuery 4 sin gamle override-logik og lader den oprindelige begivenhedsrækkefølge gælde i alle understøttede browsere, i overensstemmelse med den nuværende specifikation.

Fordelen er, at Adfærd bliver mere forudsigelig på tværs af økosystemetUlempen er, at kode, der var baseret på jQuerys tidligere rækkefølge, nu kan opføre sig anderledes og muligvis vise uventede kanttilfælde i formularer eller komplekse interaktioner i brugergrænsefladen. Dette er et af de områder, hvor det kan være særligt nyttigt at køre tests og bruge det opdaterede jQuery Migrate-plugin under opgraderinger.

Et mere elegant bibliotek, men ikke alle er enige om dets rolle

Som med enhver langtidsholdbar teknologi, Meningerne om jQuerys plads i 2026 er stærkt delte.For nogle udviklere er konklusionen enkel: Hvis du starter en helt ny webapplikation, der er målrettet mod moderne browsere, synes der overhovedet at være ringe grund til at introducere jQuery.

Kritikere peger ofte på bekymringer om ydeevne og afhængighedNative JavaScript er typisk hurtigere og undgår at tilføje snesevis af kilobytes bibliotekskode. Ældre jQuery-versioner har også en tendens til at forblive upatchede på produktionssider, hvor en ikke-triviel andel af internettet angiveligt stadig kører årtier gamle 2.x-udgivelser.

På den anden side af debatten argumenterer mange praktikere for, at jQuery er fortsat et effektivt og pragmatisk værktøj i det daglige arbejdeMens frameworks som React eller Vue dominerer store enkeltsidede applikationer, kan jQuery være et enklere valg til trinvise forbedringer, klassiske flersidede websteder eller hurtige prototyper, hvor det føles overdrevent at oprette en komplet komponentpipeline.

Der er stadig udviklere, der beskriver jQuery som et af de få JavaScript-biblioteker, der føles konsekvent behageligt at bruge, især til DOM-manipulation og eventhåndtering. Dens præcise syntaks, kædelige metoder og veletablerede idiomer kan reducere standardteksten og holde små scripts læsbare.

Denne kontrast i perspektiver betyder, at jQuery 4 sandsynligvis vil blive fortolket på forskellige måder: som en elegant modernisering af et ældre værktøj af nogle, og som en minimal vedligeholdelsesfrigivelse for en falmende æra af andreRealiteten er, at mange produktionssteder fortsat er afhængige af det, uanset om det indgår i nye projektskabeloner.

Brug i den virkelige verden: når jQuery stadig sparer tid

Ud over abstrakte argumenter viser historier fra den daglige udvikling, hvordan jQuery kan stadig løse visse problemer med meget lidt kodeEt eksempel involverer opbygning af animerede formularfelter, der kan slås til/fra, hvor nogle input kun vises, når andre er valgt eller markeret.

I det tilfælde, en udvikler forsøgte oprindeligt at skabe adfærden med almindelig JavaScript, jonglering med flere event-listenere, CSS-overgange og timingproblemer. Efter flere forsøg var scriptet vokset til mere end halvtreds linjer og led stadig af kapløbsforhold, hvor animationer ville komme i konflikt eller blive affyret i forkert rækkefølge.

Til sidst vandt frustrationen, og jQuery 4 blev tilføjet som en afhængighedVed at udnytte dens værktøjer til eventhåndtering og animation blev den samme effekt replikeret på kun et par linjer kode. Afvejningen var ligetil: et ekstra bibliotek på ~80 KB til gengæld for en langt enklere implementering og muligheden for at gå videre til andre funktioner.

Scenarier som dette fremhæver hvorfor Bibliotekets mangeårige motto "skriv mindre, gør mere" giver stadig genlyd hos nogle teamsSelv i en tid med native API'er og sofistikerede frameworks er der øjeblikke, hvor et lille script udvidet med jQuery er hurtigere at bygge og nemmere at vedligeholde end en fuldt brugerdefineret løsning.

Det betyder selvfølgelig ikke, at alle projekter drager fordel af at inkludere jQuery. Moderne JavaScript- og DOM-API'er er mere ensartede end de plejede at være, HTML5 og ECMAScript-standarder har reduceret hovedpine på tværs af browsere, og for mange enkeltsidede applikationer kan et framework eller slet intet bibliotek være det bedre valg. Pointen er mindre, at jQuery er universelt nødvendigt, og mere, at det forbliver en nyttig mulighed, når problemet og begrænsningerne stemmer overens.

Fra essentiel abstraktion til standardbiblioteksrolle

For at forstå, hvorfor jQuery 4 fokuserer på at slanke sig selv i stedet for at genopfinde sig selv, er det nyttigt at huske hvor anderledes landskabet så ud, da biblioteket opstodFor to årtier siden divergerede browsere ofte i deres fortolkning af JavaScript- og DOM-adfærd, hvilket gjorde selv basale interaktioner skrøbelige.

I det miljø, jQuery var ikke rigtig valgfrit for mange teams. Det samlede Ajax-kald, DOM-valg, eventhåndtering og animation i en ensartet API, hvilket gjorde det muligt for udviklere at stole på, at koden ville opføre sig ens på tværs af IE, Firefox, Safari og senere Chrome. Denne ensartethed var afgørende på et tidspunkt, hvor Microsoft ofte forfulgte sine egne ideer med Internet Explorer og forventede, at andre ville følge efter.

Siden da er standardiseringsorganer og browserleverandører kommet sammen om HTML5, moderne ECMAScript-versioner og langt bedre justering på tværs af browsereChromes søgemaskine og dens derivater dominerer markedet, og browsernes grundlæggende funktioner er meget højere, end de var, da jQuery først spredte sig i udviklerkredse.

Som følge heraf handler det, jQuery tilbyder i dag, mindre om at omgå inkompatibiliteter og mere om fungerer som et praktisk, velkendt "standardbibliotek" oven på JavaScriptDens funktionskædestil og korte idiomer fremmer en afslappet, næsten funktionel måde at strukturere DOM-tung kode på, selvom det underliggende sprog ikke er rent funktionelt.

For udviklere, der kun har kendt moderne værktøjer, Dybden af ​​jQuerys indflydelse kan være let at overseMange mønstre, der er introduceret eller populariseret af biblioteket, er blevet integreret i selve sproget og DOM API'erne. I den forstand forsøger jQuery 4 ikke at generobre tabt territorium, men snarere at holde biblioteket på linje med det økosystem, der voksede op omkring det.

Samlet set afspejler ændringerne i jQuery 4.0.0 – fra at droppe IE10 til at implementere ES-moduler, Trusted Types og et slankere sæt API'er – et projekt, der bevidst udvikler sig uden at opgive de millioner af websteder, der stadig er afhængige af detUdgivelsen forsøger ikke at konkurrere direkte med moderne frameworks, men den giver teams, der fortsætter med at bruge jQuery, en version, der føles hjemme i nutidens browser- og værktøjsmiljø, samtidig med at den holder døren åben for gradvis migrering, hvor det giver mening.