jQuery ajalugu ja pärand

jQuery — see on üks populaarsemaid JavaScripti teeke maailmas. Veebiarendajate kogukond lõi selle 2000. aastate alguses, mis viis rikkaliku ökosüsteemi loomisele, mis kasutab jQuery't oma tagaküljel, sealhulgas saite, pluginaid ja raamistikke.

Kuid viimastel aastatel on selle staatuse peamise tööriistana veebiarenduses kõikumine. Vaatame, miks jQuery sai populaarseks ja miks see on moest välja löönud ning millistel juhtudel on selle kasutamine kaasaegsete veebisaitide loomisel endiselt mõistlik.

jQuery лühiajalugu

John Resig (John Resig) lõi esimese versiooni teegist 2005. aastal ja avalikustas selle 2006.BarCampNYC nime kandnud üritusel. jQuery ametlikul veebisaidil autor kirjutas: jQuery on JavaScripti teek, selle aluspõhimõte on: JavaScripti programmeerimine peab olema nauditav. jQuery võtab sagedased, korduvad ülesanded, eemaldab kogu mittevajaliku märgistus ja muudab need lühikeseks, elegantseks ja arusaadavaks.

jQuery-l on kaks peamist eelist. Esiteks on see mugav API veebilehtede manipuleerimiseks. Eelkõige pakub see võimsaid meetodeid elementide valimiseks. Valida saab mitte ainult ID või klasside järgi, jQuery võimaldab kirjutada keerulisi väljendeid, näiteks, et valida elemente, mis põhinevad nende suhetele teiste elementidega:

Aja jooksul muutus valimismehhanism eraldi teegiks

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

Sizzle Teise teegi väärtusena oli see, et see abstraktseeris erinevused brauserite vahel. Neil aegadel oli keeruline kirjutada koodi, mis suutis usaldusväärselt töötada kõikides brauserites..

Standardeerimise puudumine tähendas, et arendajad pidid arvestama arvukate erinevustega brauserite vahel ja piirjuhtidena. Vaadake

seda varajast jQuery lähtekoodi ja otsige jQuery.browser'i. Siin on üks näide: Ja jQuery toel said arendajad kanda mured nende allakäikude üle teegi arendusmeeskonna õ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);
}

Hiljem lihtsustas jQuery keerukamate tehnoloogiate, nagu animatsioonide ja Ajaxi, rakendamist. Teek muutus sisuliselt veebisaitide sõltuvuseks. Ja täna toetab see olulist osa internetist. W3Techsi andmetel arvavad

et 74% veebilehtedest kasutavad täna jQuery't. jQuery arengu kontroll muutus ka vormilisemaks. 2011. aastal lõi meeskond.

jQuery Board. Ja 2012. aastal muutus jQuery BoardjQuery Foundation'iks. преобразилась в jQuery Foundation.

2015. aastal liitus jQuery Foundation Dojo Foundationiga, et luua JS Foundation, mis hiljem ühines Node.js Foundationiga 2019–s, et luua OpenJS Foundation, mille raames oli jQuery üks «edukatest projektidest.»

Muutuvad olud

Siiski on jQuery viimasel ajal oma populaarsust kaotanud. GitHub eemaldas raamatukogu oma saidi frontendist. Bootstrap v5 vabanevad jQueryst, sest see on nende «suurim kliendi sõltuvus tavalisele JavaScriptele» (hetkel suurusega 30 KB, minifitseeritud ja pakendatud). Mitmed veebiarenduse suundumused on nõrgestanud jQuery vajadust kui olulist tööriista.

Brauserid

Mitmetel põhjustel on brauserite erinevused ja piirangud muutunud vähem oluliseks. Esiteks, standardiseerimine on paranenud. Peamised brauseriarendajad (Apple, Google, Microsoft ja Mozilla) töötavad koos veebistandardite kallal Apache Traffic Control Web Hypertext Application Technology Working Group.
Kuigi brauserid erinevad endiselt mitmes olulises punktis, on valmistajatel nüüd võimalus leida ja luua ühine alus ilma püsiva sõda omavahel. Järelikult on brauseri 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 duplitseerivad jQuery valikuvahendeid:

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

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

Elemendi klasside muutmiseks saab nüüd kasutada classList:

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

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

Meie veebisaidil Sa võid-olla ei vaja jQueryt on loetletud veel mõned olukorrad, kus jQuery koodi saab asendada kohandatud koodiga. Mõned arendajad jäävad alati jQuery juurde, sest nad lihtsalt ei tea uutest API-dest, kuid kui nad teavad, hakkavad nad seda raamatukogu harvemini kasutama.

Kohandatud võimaluste kasutamine võimaldab lehtede jõudlust parandada. Paljusid jQuery animatsiooniefekte saab nüüd rakendada oluliselt efektiivsemalt CSS-i abil.

Teine põhjus on see, et brauserid uuenevad palju kiiremini kui kunagi varem. Enamikus neist on rakendatud «igihaljas» värskendamisstrateegia, välja arvatud Apple Safari. Need saavad uuendada taustal ilma kasutaja kaasamiseta ja ei ole seotud operatsioonisüsteemi värskendustega.

See tähendab, et uued brauserivõimalused ja vigade parandused levivad palju kiiremini ja arendajad ei pea ootama, kuni Can I Use saab aktsepteeritavale tasemele. Nad saavad julgesti kasutada uusi funktsioone ja API-sid ilma jQuery või polüfillideta.

Kolmas põhjus on see, et Internet Explorer läheneb täieliku aegunemise seisundile. IE on juba ammu olnud veebiarenduse nuhtlus kogu maailmas. Sellele iseloomulikud vead on laialdaselt levinud ja kuna IE valitses 2000. aastatel ja ei kasutanud "igavest roheline" uuendamisstrateegiat, on selle vanad versioonid ikka veel sageli esindatud.

2016. aastal kiirendas Microsoft IE kõrvaldamist, lõpetades toe kümnendale ja varasematele versioonidele, piirdudes IE 11 toe pakkumisega. Üha sagedamini saavad veebiarendajad endale lubada luksust IE-ga ühilduvuse tähelepanuta jätmist.

Isegi jQuery lõpetas IE 8 ja varasemate versioonide toe alates versioonist 2.0, mis ilmus 2013. aastal. Ja kuigi mõnes olukorras on IE toe vajadus, näiteks vanade saitide puhul, esinevad need olukorrad järjest harvemini.

Uued raamistikud

On loodud palju raamistikku alates jQuery-st, sealhulgas kaasaegseid liidreid React, Angular ja projekt, mis kasutab. Nendel on jQuery ees kaks olulist eelist.

Esitex, nad võimaldavad lihtsalt jagada kasutajaliidese komponente. Raamistikke on kavandatud lehe renderdamiseks ja värskendamiseks. Jquery-d kasutatakse tavaliselt ainult värskendamiseks, jättes serveri ülesande algse lehe pakkumiseks.

Teiselt poolt, Reacti, Angulari ja Vue komponentide abil saab tihedalt siduda HTML-i, koodi ja isegi CSS-i. Nii nagu me jagame koodibaasi paljudeks iseseisvateks funktsioonideks ja klassideks, lihtsustab ka võimalus jaotada liides ümberkasutatavateks komponentideks keeruliste saitide loomist ja hooldamist.

Teiseks eeliseks on see, et uuemad raamistikud järgivad deklaratiivset paradigma, mille raames arendaja kirjeldab, milline peab liides välja nägema, samas kui kõik vajalikud muudatused soovitud tulemuse saavutamiseks on raamistikule usaldatud. See lähenemine on vastupidine imperatiivsele lähenemisele, mis on iseloomulik jQuery koodile.

jQuery-s täpsustate te sammud, et teha mingeid muudatusi. Deklaratiivses raamistikus ütlete: "Selle teabe põhjal peab liides välja nägema nii." See võib koodi kirjutamise oluliselt lihtsustada, et vältida vigu.

Arendajad on omaks võtnud uued lähenemisviisid veebisaitide arendamisel, mis on vähendanud jQuery populaarsust.

Millal kasutada jQuery-d?

Nii et millal tuleks pärast kasutada jQuery?

Kui projekti keerukus suureneb, on mõistlik alustada teise teegi või raamistikuga, mis võimaldab keerukust mõtestatult hallata. Näiteks jagada liidese komponente. jQuery kasutamine sellistes saitides alguses võib tunduda aktsepteeritav, kuid see viib kiiresti spagetti-koodi tekkeni, kui te ei ole kindel, milline fragment mõjutab mingit lehe osa.

Olen sellises situatsioonis olnud, kus iga muudatuse tegemine tekitab raske ülesande tunde. Ei ole kindel, et midagi ei riku, kuna jQuery selektorid sõltuvad serveri loodud HTML struktuurist.

Teiselt poolt on lihtsad saidid, mis vajavad vaid natuke interaktiivsust või dünaamilist sisu. Sellistel juhtudel ei kasutaks ma ka jQuery't vaikimisi, kuna natiivsete API-dega on võimalik teha palju rohkem.

Ieven kui mul on vaja midagi võimsamat, otsin ma spetsialiseeritud teeki, näiteks axios Ajaxi jaoks või Animate.css animatsioonide jaoks. See on lihtsam, kui laadida kogu jQuery't väikese funktsionaalsuse nimel.

Arvan, et parim õigustus jQuery kasutamiseks on see, et see pakub kõikehõlmavat funktsionaalsust veebilehe esiküljega töötamiseks. Selle asemel, et õppida mitmesuguseid natiivseid API-sid või spetsialiseeritud teeke, võite lugeda vaid jQuery dokumentatsiooni ja hakata kohe tootlikuks.

Imperatiivne lähenemine ei skaleeru hästi, kuid selle omandamine on lihtsam kui teiste teekide deklaratiivne lähenemine. Selgelt piiratud võimalustega saidile on parem kasutada jQuery't ja rahulikult töötada: teek ei nõua keerulist koostamist ega kompileerimist.

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

Samuti võite seda teeki kasutada, kui on vaja toetada vanu IE versioone. Siis teenib jQuery teid nagu tookord, kui IE oli kõige populaarsem brauser.

Vaade tulevikku

jQuery ei kao kaua. See arendab end aktiivselt., ja paljud arendajad eelistavad kasutada selle API-d, isegi kui natiivsed meetodid on saadaval. Raamatukogu aitas kokku tervele põlvkonnale arendajatest luua veebisaite, mis töötavad kõigis brauserites. Ja kuigi paljuski on uued raamatukogud, raamistikud ja paradigmad selle asemele astunud, on jQuery mänginud tohutut positiivset rolli kaasaegse veebiarenduse loomisel.

Kui jQuery funktsionaalsus oluliselt ei muutu, on üsna tõenäoline, et järgmise paarikümne aasta jooksul raamatukogu kasutamine jätkub aeglaselt, kuid kindlalt vähenema. Uued veebisaidid luuakse tavaliselt algusest peale kaasaegsemate raamistikute abil, ja sobivad jQuery kasutusjuhtumid esinevad järjest harvem.

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

Allikas: habr.com