jQuery ajalugu ja pärand

jQuery — see on maailma populaarseim JavaScript'i raamatukogu. Veebiarendajate kogukond lõi selle 2000. aastate lõpus, mis viis rikkaliku ökosüsteemi, mille hulka kuuluvad saidid, pistikprogrammid ja raamistikud, mis kasutavad jQuery't.

Kuid viimastel aastatel on selle staatuse peamise veebiarendamise tööriistana kõigutatud. Vaatame, miks jQuery sai populaarseks ja miks see on moest välja läinud, samuti millal on paradoksaalselt endiselt mõistlik seda kasutada kaasaegsete saitide loomisel.

jQuery lühike ajalugu

John Resig (John Resig) lõi raamatukogu esimese versiooni 2005. aastal ja avalikustas selle 2006.aastal üritusel nimega BarCampNYC. jQuery ametlikul veebilehel kiri ütles:

jQuery — see on JavaScripti raamatukogu, mille põhitees on: JavaScripti programmeerimine peab olema nauditav. jQuery võtab sagedased, korduvad ülesanded, kõrvaldab kogu tarbetu markeeringu ning muudab need lühemaks, elegantsemaks ja arusaadavamaks.

jQuery-l on kaks peamist eelist. Esiteks on see mugav API veebilehtede manipuleerimiseks. Sealhulgas pakub see võimsaid meetodeid elementide valimiseks. Saate valida mitte ainult ID-de või klasside järgi; jQuery võimaldab kirjutada keerukaid avaldisi, et valida elemente vastavalt nende seostele teiste elementidega:

// Select every item within the list of people within the contacts element
$('#contacts ul.people li');

Aja jooksul muutus valikumehhanism eraldi raamatukoguks Sizzle.

Teiseks eelisteks oli see, et raamatukogu abstraheeris erinevused brauserite vahel. Neil päevadel oli keeruline kirjutada koodi, mis suudaks usaldusväärselt töötada kõikides brauserites.

Standardimise puudumine tähendas, et arendajad pidid arvestama mitmete erinevustega brauserite vahel ja piirjuhtumitega. Vaadake seda varajast jQuery lähtekoodi ja otsige jQuery.browser'i. Siin on üks näide: Ja tänu jQuery-le said arendajad kõik need mured sellest, kuidas need kõik need takistused kõrvaldada, raamatukogu arendustiimi õlgadele.

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

Ja kuna jQuery, saavad arendajad kõik need mured libisemise üle jätta raamatukogu arendusmeeskonna õlgadele.

Hiljem lihtsustas jQuery keerukamate tehnoloogiate, nagu animatsioonid ja Ajax, rakendamist. Raamatukogust on saanud tõeliselt standardne veebilehtede sõltuvus. Tänapäeval toetab see suurt osa Internetist. W3Techs hindab, et 74% tänapäeva veebilehtedest kasutab jQuery.

jQuery arengu kontroll on muutunud formaalsemaks. 2011. aastal lõi meeskond jQuery Board. 2012. aastal muutus jQuery Board jQuery Foundationiks.

. 2015. aastal liitus jQuery Foundation Dojo Foundationiga, et luua JS Foundation, mis liitus seejärel Node.js Foundationiga 2019OpenJS Foundationi loomise jaoks , kus jQuery oli üks „murrangulisi projekteMuutuvad olud.»

Kuid viimastel aastatel on jQuery

kaotanud oma populaarsust . GitHubeemaldas raamatukogu oma saiti esiosa. . Bootstrap v5jätab jQuery kõrvale , kuna see on tema „suurim kliendi sõltuvus tavalise JavaScripti jaoks“ (praegu 30 KB suuruses, minimeeritud ja pakitud). Mitmed suundumused veebiarenduses on nõrgestanud jQuery positsiooni hädavajaliku tööriistana.» (praegu 30 KB suuruses, minimeeritud ja pakitud). Mitmed veebiarenduse suundumused on nõrgestanud jQuery positsiooni kui vajalikku tööriista.

Brauserid

Mitmete põhjuste tõttu on brauseridest tingitud erinevused ja piirangud muutunud vähem oluliseks. Esiteks, standardiseerimine on paranenud. Peamised brauseri arendajad (Apple, Google, Microsoft ja Mozilla) töötavad koos välja veebi-standardid raames Web Hypertext Application Technology Working Group.
Kuigi brauserid erinevad endiselt üksteisest mitmete oluliste aspektide poolest, on tarnijatel vähemalt võimalus leida ja luua ühtne alus, mitte püsiv sõda üksteisega. Vastavalt on brauserite API-d saanud uusi võimalusi. Näiteks Fetch API suudab asendada jQuery Ajax-funktsioone:

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

Meetodid querySelector ja querySelectorAll korrata jQuery valikutööriistu:

// jQuery
const fooDivs = $('.foo div');

// native
const fooDivs = document.querySelectorAll('.foo div');

Elementide klassidega manipuleerimise nüüd saab teha classList:

// jQuery
$('#warning').toggleClass('visible');

// native
document.querySelector('#warning').classList.toggle('visible');

Lehelt You Might Not Need jQuery on loetletud veel mõned olukorrad, kus jQuery koodi saab asendada natiivse koodiga. Mõned arendajad kasutavad alati jQuery-d, sest nad ei tea lihtsalt uutest API-dest, kuid kui nad saavad teadlikuks, hakkavad nad seda teeki harvemini kasutama.

Natiivsete võimaluste kasutamine võimaldab suurendada lehtede jõudlust. Paljusid jQuery animatsiooniefekte saab nüüd rakendada oluliselt efektiivsemalt CSS-i abiga.

Teine põhjus on see, et brauserid uuenevad palju kiiremini kui varem. Enamik neist kasutab „igihaljast“ uuendamise strateegiat, välja arvatud Apple Safari. Need võivad uuendada salaja, ilma kasutaja sekkumiseta, ja ei ole seotud operatsioonisüsteemide uuendustega.

See tähendab, et uued brauserifunktsioonid ja veaparandused levivad palju kiiremini, ega peavad arendajad ootama, kuni Can I Use jõuab vastuvõetava tasemeni. Nad saavad julgelt uusi funktsioone ja API-sid kasutada ilma jQuery või polüfiilide laadimiseta.

Kolmas põhjus on see, et Internet Explorer läheneb täieliku vananenud olekuni. IE on juba ammu olnud veebiarenduse nuhtluseks üle kogu maailma. Tema iseloomulikud vead olid laialdaselt levinud, ja kuna IE domineeris 2000. aastatel ja ei kasutanud „igihaljast“ uuendamise strateegiat, on tema vanu versioone endiselt sageli näha.

2016. aastal kiirendas Microsoft IE väljakutsumist, lõpetades toe kümnendat ja varasemaid versioone, piirdudes IE 11 toe pakkumisega. Üha sagedamini saavad veebiarendajad endale lubada luksust IE toetamisest kõrvale jätta.

Isegi jQuery lõpetas IE 8 ja madalamate versioonide toe alates versioonist 2.0, mis ilmus 2013. aastal. Kuigi teatud olukordades on endiselt vajalik IE toetus, näiteks vanadel veebisaitidel, esinevad need situatsioonid järjest harvem.

Uued raamistikud

Alates jQuery ilmumisest on loodud mitmeid raamistikke, sealhulgas kaasaegsed liidrid React, Angular ja Vue. Nendel on kaks olulist eelist jQuery ees.

Esiteks, need võimaldavad hõlpsasti jagada kasutajaliidese komponente. Raamistikke on projekteeritud lehe renderdamise ja uuendamise toetamiseks. jQuery-d kasutatakse tavaliselt ainult uuendamiseks, jättes serverile ülesande esialgse lehe pakkumise.

Teisest küljest võimaldavad Reacti, Angulari ja Vue komponendid HTMLi, koodi ja isegi CSSi tihedat sidumist. Nii nagu jagame koodibaasi paljude iseseisvate funktsioonide ja klasside kaupa, lihtsustab kasutajaliidese jagamine korduvkasutatavate komponentideks keerukate veebisaitide loomist ja hooldamist.

Teiseks eeliseks on see, et uuemad raamistikud järgivad deklaratiivset paradigmat, kus arendaja kirjeldab, milline kasutajaliides peaks välja nägema, ja raamistik kannab vastutust kõigi vajalike muudatuste tegemise eest soovitud tulemuse saavutamiseks. See lähenemine on vastuolus imperatiivse lähenemisega, mis on iseloomulik jQuery koodile.

jQuery-s määrate te selgelt sammud, et teha mingeid muudatusi. Deklaratiivses raamistikus aga ütlete: "Nende andmete põhjal peaks liides välja nägema nii". See võib oluliselt lihtsustada vigade vaba koodi kirjutamist.

Arendajad on omaks võtnud uusi lähenemisi veebilehtede arendamiseks, mistõttu jQuery populaarsus on vähenenud.

Millal kasutada jQuery?

Nii millal tuleks kasutada jQuery?

Kui projekti keerukus kasvab, on parem alustada teise teegi või raamistiku kasutamisest, mis võimaldab mõtestatult keerukust hallata. Näiteks komponentideks jagamine kasutajaliideses. jQuery kasutamine sellistes veebilehtedes võib alguses tunduda vastuvõetav, kuid see toob kiiresti kaasa spagetikoodi tekkimise, kui te ei ole kindel, milline fragment mõjutab mingit osa lehelt.

Olen olnud sellises olukorras, kus igasugune muudatus tundub keeruline ülesanne. Ei saa olla kindel, et midagi katki ei lähe, kuna jQuery selektorid sõltuvad serveri loodud HTML struktuurist.

Teiselt poolt on lihtsad veebilehed, mis vajavad vaid natuke interaktiivsust või dünaamilist sisu. Sellistes olukordades ei sooviks ma samuti jQueryd vaikimisi kasutada, sest natiivsete APIde kaudu on võimalik teha palju rohkem.

Isegi kui mul oleks vaja midagi võimsamat, otsiksin ma spetsialiseeritud teeki, näiteks axios Ajaxi jaoks või Animate.css animatsioonide jaoks. See on lihtsam, kui laadida alla kogu jQuery väikese funktsionaalsuse nimel.

Mõtle, et jQuery kasutamise parimaks põhjuseks on see, et see pakub põhjalikku funktsionaalsust veebisaidi front-end'i jaoks. Selle asemel, et tudeerida mitmesuguseid natiivseid API-sid või spetsialiseeritud teeke, võite lugeda lihtsalt jQuery dokumentatsiooni ja olla kohe produtktiivne.

Imperatiivne lähenemine ei skaalu hästi, kuid selle mõistmine on lihtsam kui teiste teekide deklaratiivne lähenemine. Selgelt piiratud võimalustega saidi puhul on parem kasutada jQuery-d ja töötada rahulikult: raamatukogu ei vaja keerulist koostamist või kompileerimist.

Samuti on jQuery hea variant, kui olete kindel, et veebisait ei muutu aja jooksul keerukamaks, ja kui teid ei häiri natiivne funktsionaalsus, mis kindlasti nõuab rohkem koodi kirjutamist kui jQuery.

Samuti saate seda teeki kasutada, kui peate toetama vanu IE versioone. Sel juhul teenib jQuery teid nagu tollal, kui IE oli kõige populaarsem brauser.

Pilguheit tulevikku

jQuery ei kao niipea. See areneb aktiivselt, ja paljud arendajad eelistavad kasutada selle API-t, isegi kui on olemas natiivmeetodid. Raamatukogu aitas tervele järjekonnale arendajatest luua veebisaite, mis töötavad kõikides brauserites. Ja kuigi paljuski on uued raamatukogud, raamistikud ja paradigmaid selle asendanud, on jQuery mänginud tohutut positiivset rolli kaasaegse veebilehe loomisel.

Kui jQuery funktsionaalsus ei muutu olulisel määral, on täiesti tõenäoline, et järgmise paarikümne aasta jooksul selle raamatukogude kasutamine jätkab aeglast, kuid järkjärgulist langust. Uued veebisaidid luuakse tavaliselt kohe kaasaegsete raamistikude kasutamisega ning sobivate jQuery kasutusscenario'de esinemine on üha haruldasem.

Mõnele ei meeldi veebiarendustööriistade kiire vananemise intensiivsus, kuid minu jaoks on see märk kiirest progressist. jQuery võimaldas meil teha palju paremini. Sama kehtib ka tema järgijate kohta.

Allikas: habr.com