jQuery ā JavaScript-bibliotheek ter wereld. De gemeenschap van webontwikkelaars creĆ«erde het aan het eind van de jaren 2000, wat leidde tot de opkomst van een rijke ecosysteem van websites, plugins en frameworks die jQuery gebruiken.
Maar in de afgelopen jaren is de status als belangrijkste tool voor webontwikkeling wankel geworden. Laten we kijken naar waarom jQuery zo populair werd en waarom het uit de gratie is geraakt, en in welke gevallen het nog steeds zinvol is om het te gebruiken voor moderne websites.
Korte geschiedenis van jQuery
John Resig () creƫerde de eerste versie van de bibliotheek in 2005 en - op een evenement genaamd BarCampNYC. Op de schreef de auteur:
jQuery is een JavaScript-bibliotheek, gebaseerd op het credo: Programmeren in JavaScript moet leuk zijn. jQuery neemt veelvoorkomende, herhalende taken, verwijdert onnodige markup en maakt ze kort, elegant en begrijpelijk.
jQuery heeft twee hoofdvoordelen. Ten eerste is er de handige API voor het manipuleren van webpagina's. Het biedt krachtige methoden voor het selecteren van elementen. Je kunt niet alleen op ID of klassen selecteren, jQuery maakt het mogelijk om complexe expressies te schrijven, bijvoorbeeld om elementen te selecteren op basis van hun relaties met andere elementen:
// Select every item within the list of people within the contacts element
$('#contacts ul.people li');In de loop der tijd evolueerde het selectiemechanisme naar een aparte bibliotheek .
Het tweede voordeel van de bibliotheek was dat het de verschillen tussen browsers abstracteerde. In die tijd was het moeilijk om code te schrijven die betrouwbaar werkte in alle browsers.
Het gebrek aan standaardisatie betekende dat ontwikkelaars rekening moesten houden met talloze verschillen tussen browsers en randgevallen. Kijk eens naar en zoek naar jQuery.browser. Hier is een van de voorbeelden:
// If Mozilla is used
if ( jQuery.browser == "mozilla" || jQuery.browser == "opera" ) {
// Use the handy event callback
jQuery.event.add( document, "DOMContentLoaded", jQuery.ready );
// If IE is used, use the excellent hack by Matthias Miller
// http://www.outofhanwell.com/blog/index.php?title=the_window_onload_problem_revisited
} else if ( jQuery.browser == "msie" ) {
// Only works if you document.write() it
document.write("<scr" + "ipt id=__ie_init defer=true " +
"src=javascript:void(0)></script>");
// Use the defer script hack
var script = document.getElementById("__ie_init");
script.onreadystatechange = function() {
if ( this.readyState == "complete" )
jQuery.ready();
};
// Clear from memory
script = null;
// If Safari is used
} else if ( jQuery.browser == "safari" ) {
// Continually check to see if the document.readyState is valid
jQuery.safariTimer = setInterval(function(){
// loaded and complete are both valid states
if ( document.readyState == "loaded" ||
document.readyState == "complete" ) {
// If either one are found, remove the timer
clearInterval( jQuery.safariTimer );
jQuery.safariTimer = null;
// and execute any waiting functions
jQuery.ready();
}
}, 10);
}Dankzij jQuery konden ontwikkelaars de zorgen over al deze valkuilen op de schouders van het team dat de bibliotheek ontwikkelde leggen.
Later vereenvoudigde jQuery de implementatie van complexere technologieƫn, zoals animaties en Ajax. De bibliotheek is feitelijk een standaard afhankelijkheid geworden voor websites. En vandaag de dag ondersteunt het een enorm deel van het internet. W3Techs schat dat .
Het toezicht op de ontwikkeling van jQuery is ook formeler geworden. In 2011 richtte het team . En in 2012 transformeerde de jQuery Board.
In 2015, de jQuery Foundation fuseerde met de Dojo Foundation,, die later samenkwam met de Node.js Foundation in- om de, waar jQuery een van de ".Ā»
Veranderende omstandigheden
Echter, in de afgelopen jaren heeft jQuery . GitHub. Bootstrap v5 , omdat dit de "" is (momenteel 30 KB groot, geminimaliseerd en verpakt). Enkele trends in webontwikkeling hebben de positie van jQuery als een noodzakelijke tool verzwakt.
Browsers
Om verschillende redenen zijn de verschillen en beperkingen van browsers minder belangrijk geworden. Ten eerste is de standaardisatie verbeterd. Hoofdentwikkelaars van browsers (Apple, Google, Microsoft en Mozilla) werken samen aan binnen.
Hoewel browsers nog steeds van elkaar verschillen in verschillende belangrijke opzichten, hebben verkopers tenminste een manier om een gemeenschappelijke basis te vinden en te creƫren in plaats van met elkaar. Als gevolg hiervan hebben browser-API's nieuwe mogelijkheden gekregen. Bijvoorbeeld, kan Ajax-functionaliteiten van jQuery vervangen:
// jQuery
$.getJSON('https://api.com/songs.json')
.done(function (songs) {
console.log(songs);
})
// native
fetch('https://api.com/songs.json')
.then(function (response) {
return response.json();
})
.then(function (songs) {
console.log(songs);
});Methoden en dupliceren de selectiemethoden van jQuery:
// jQuery
const fooDivs = $('.foo div');
// native
const fooDivs = document.querySelectorAll('.foo div');Elementklassen kunnen nu worden beheerd met :
// jQuery
$('#warning').toggleClass('visible');
// native
document.querySelector('#warning').classList.toggle('visible');staat geschreven: een paar situaties opgesomd waarin jQuery-code kan worden vervangen door native code. Sommige ontwikkelaars houden altijd vast aan jQuery omdat ze gewoon niet op de hoogte zijn van nieuwe API's, maar zodra ze erachter komen, gebruiken ze deze bibliotheek minder vaak.
Het gebruik van native mogelijkheden verbetert de prestaties van pagina's. Veel kunnen nu met CSS.
De tweede reden is dat browsers veel sneller worden bijgewerkt dan vroeger. In de meeste van hen wordt een toegepast, uitgezonderd Apple Safari. Ze kunnen op de achtergrond worden bijgewerkt zonder dat de gebruiker erbij betrokken is en zijn niet gebonden aan besturingssysteemupdates.
Dit betekent dat nieuwe mogelijkheden van browsers en bugfixes veel sneller worden verspreid, en ontwikkelaars hoeven niet te wachten tot het aandeel zal voldoende niveau bereiken. Ze kunnen met vertrouwen nieuwe functies en API's gebruiken zonder jQuery of polyfills te laden.
De derde reden is dat Internet Explorer bijna volledig irrelevant wordt. IE is al lange tijd een vloek voor webontwikkeling over de hele wereld. De typische bugs waren wijdverspreid, en omdat IE in de jaren 2000 domineerde en geen "evergreen" update-strategie volgde, komen oude versies nog steeds vaak voor.
In 2016 versnelde Microsoft de afbouw van IE, voor versie tien en eerdere versies, met alleen ondersteuning voor IE 11. En steeds vaker kunnen webontwikkelaars het zich veroorloven omcompatibiliteit met IE te negeren.
Zelfs jQuery is gestopt met ondersteuning voor IE 8 en lager vanaf , die in 2013 uitkwam. En hoewel ondersteuning voor IE in sommige gevallen nog steeds noodzakelijk is, bijvoorbeeld op oudere websites, komen deze situaties steeds vaker voor.
Nieuwe frameworks
Sinds de introductie van jQuery zijn er talloze frameworks ontwikkeld, waaronder moderne leiders zoals , en . Zij hebben twee belangrijke voordelen ten opzichte van jQuery.
Ten eerste stellen ze ontwikkelaars in staat om eenvoudig de gebruikersinterface in componenten te splitsen. Frameworks zijn ontworpen om de rendering en het bijwerken van pagina's te verwerken. jQuery wordt meestal alleen gebruikt voor updates, met de server die de taak heeft om de initiƫle pagina te leveren.
Aan de andere kant stellen componenten van React, Angular en Vue ontwikkelaars in staat om HTML, code en zelfs CSS nauw met elkaar te verbinden. Net zoals we onze codebasis splitsen in veel zelfvoorzienende functies en klassen, vereenvoudigt de mogelijkheid om de interface in herbruikbare componenten te splitsen de bouw en het onderhoud van complexe sites.
Het tweede voordeel is dat modernere frameworks de declaratieve paradigm volgen, waarbij de ontwikkelaar beschrijft hoe de interface eruit moet zien, terwijl het framework alle nodige wijzigingen aanbrengt om het gewenste resultaat te bereiken. Deze aanpak staat in contrast met de imperatieve benadering die kenmerkend is voor jQuery-code.
In jQuery schrijf je expliciet de stappen om wijzigingen aan te brengen. In een declaratief framework zeg je: "Volgens deze gegevens moet de interface er zo uitzien." Dit kan het schrijven van foutloze code aanzienlijk vergemakkelijken.
Ontwikkelaars hebben nieuwe benaderingen voor websiteontwikkeling omarmd, waardoor de populariteit van jQuery afnam.
Wanneer jQuery gebruiken?
Dus wanneer volgt jQuery gebruiken?
Als de complexiteit van een project toeneemt, is het beter om met een andere bibliotheek of framework te beginnen dat het mogelijk maakt om de complexiteit op een zinvolle manier te beheren. Bijvoorbeeld door de interface in componenten op te splitsen. Het gebruik van jQuery op dergelijke websites kan aanvankelijk acceptabel lijken, maar dit leidt snel tot spaghetti-code, waarbij je niet zeker weet welk stukje op welk deel van de pagina invloed heeft.
Ik ben in zo'n situatie geweest; bij het proberen om enige wijziging aan te brengen, voelt het als een moeilijke taak. Je kunt er niet zeker van zijn dat je niets breekt, omdat jQuery-selectors afhankelijk zijn van de HTML-structuur die door de server is gemaakt.
Aan de andere kant van het spectrum zijn er eenvoudige websites die slechts een beetje interactiviteit of dynamische inhoud vereisen. In dergelijke gevallen zou ik ook niet standaard jQuery gebruiken, omdat je met de native API veel meer kunt doen.
Zelfs als ik iets krachtigers nodig heb, zal ik zoeken naar een gespecialiseerde bibliotheek, zoals voor Ajax of voor animaties. Dit is eenvoudiger dan jQuery in zijn geheel te laden voor een kleine functionaliteit.
Ik denk dat de beste rechtvaardiging voor het gebruik van jQuery is dat het uitgebreide functionaliteit biedt voor frontendwerk van de website. In plaats van verschillende native API's of gespecialiseerde bibliotheken te leren, kun je gewoon de jQuery-documentatie lezen en meteen productief zijn.
De imperatieve aanpak schaalt slecht, maar is eenvoudiger te leren dan de declaratieve aanpak van andere bibliotheken. Voor een site met duidelijk beperkte mogelijkheden is het beter om jQuery toe te passen en gewoon te werken: de bibliotheek vereist geen complexe opbouw of compilatie.
Bovendien is jQuery handig als je er zeker van bent dat de site in de loop van de tijd niet complexer zal worden, en als je je geen zorgen maakt over de native functionaliteit, die ongetwijfeld meer code vereist dan jQuery.
Je kunt deze bibliotheek ook gebruiken als je oude versies van IE moet ondersteunen. Dan zal jQuery voor je werken zoals in de tijd dat IE de populairste browser was.
Een blik op de toekomst
jQuery zal nog wel een tijdje blijven. Het , en veel ontwikkelaars geven de voorkeur aan het gebruik van de API, zelfs met de beschikbaarheid van native methodes. De bibliotheek heeft een hele generatie ontwikkelaars geholpen om websites te maken die op alle browsers werken. En hoewel in veel opzichten nieuwe bibliotheken, frameworks en paradigma's haar hebben vervangen, heeft jQuery een enorme positieve rol gespeeld in het creƫren van het moderne web.
Als de functionaliteit van jQuery niet aanzienlijk verandert, is het zeer waarschijnlijk dat het gebruik van de bibliotheek de komende jaren langzaam maar gestaag zal afnemen. Nieuwe websites worden doorgaans vanaf het begin gebouwd met modernere frameworks, en de toepasselijke gebruiksscenario's voor jQuery komen steeds minder vaak voor.
Sommigen zijn niet blij met de snelheid waarmee webontwikkelingstools verouderen, maar voor mij getuigt dit van snelle vooruitgang. jQuery heeft ons in staat gesteld om veel dingen beter te doen. Hetzelfde geldt voor haar opvolgers.
Bron: habr.com
