# varför diskuterar vi ens framtiden för jQuery?

missa inte videon ovanför artikeln!

eftersom jQuery fortfarande kör majoriteten av frontend-webblogiken! Den driver cirka 70% av de bästa webbsidorna och 20% av hela webben (källa). Det är enormt!

men detta gör frågan om dess framtid ännu främling.

jQuery har problem. Det är överallt och det är inte riktigt framtidssäker. Det var ett fantastiskt verktyg när det släpptes tillbaka 2006 men kärnfrågorna som det fixade tillbaka vid den tiden är inte längre problem. Istället kan du nu stöta på fler problem när du använder jQuery.

för att förstå detta, låt oss överväga de problem som jQuery fixade tillbaka 2006.

JavaScript var typ av trasiga och webbläsare genomfört det mycket annorlunda

detta var en av de stora saker jQuery hjälpte till med. Plötsligt hade du ett lättanvänt API som gjorde det möjligt för dig att manipulera DOM. Och ännu bättre än så: samma API fungerade i alla större webbläsare!

$('h1').text('Awesome!')

JavaScript och webben som helhet var långt mindre mogna

jQuery tillät utvecklare att helt enkelt” göra mer ” på webben – på frontend för att vara exakt. Att skapa engagerande användargränssnitt (för vilka du behöver JavaScript) var lättare eftersom du kunde använda ett väldokumenterat API. Animera element, lägga till och ta bort innehåll, ändra stilar och ombeställa objekt var betydligt lättare att uppnå än med vanilj JavaScript. jQuery lade också till ett kraftfullt och ändå tillgängligt AJAX API som också gjorde det enkelt att skicka bakgrundsförfrågningar. Detta är ett kärnbyggnadsblock för JavaScript-drivna UIs eftersom du inte behöver ladda en ny sida vid varje användaråtgärd och kan ladda eller manipulera data på serversidan bakom kulisserna.

    lär dig Vue.js

    Vue.js gör det enkelt att bygga reaktiva webbsidor. En trevlig syntax + kraftfulla funktioner-det är inte det värsta paketet du kan få.

    lär dig reagera

    reagera är ett bra alternativ till Vue.js. Det är extremt populärt och du bör absolut inte missa det!

    lär dig vinkel

    vinkel startade allt! Lär dig ramverket som är moderen till React.js och Vue!

# Vad har förändrats?

problemen som åtgärdats av jQuery är inte längre problem.

JavaScript mognat, webbläsarkompatibilitet blev mycket bättre. Vi har ett levande frontend-utvecklingsekosystem med tusentals paket och verktyg, vi kan använda mer kraftfulla AJAX-bibliotek som Axios om vi vill.

detta betyder inte att allt är bra men kärnproblemen som fixades av jQuery existerar inte längre.istället är jQuery nu ett verktyg som ofta (inte alltid förstås) används av mindre erfarna webbutvecklare som aldrig bytte till vanilj JavaScript eller ramar som Angular eller React.

och det är viktigt att förstå förresten: vi pratar inte bara om jQuery vs Angular. Vanilj JavaScript är ett riktigt alternativ!

medan DOM traversal och manipulation var mycket svårare 2006, fick vi många funktioner som querySelector inbyggd i vanilj JavaScript nu. Dessa saker fungerar och de fungerar även över webbläsare.

Om du har möjlighet att använda vanilj JavaScript istället för att uppnå i princip samma sak med jQuery, är det uppenbarligen bättre att använda vaniljalternativet. Du sparar det extra paketet nedladdning och du behöver inte lära sig en extra syntax.

#det är inte bara vanilj JavaScript…

det är inte bara vanilj JavaScript men. Vi fick helt enkelt bättre alternativ idag.

vanilj JavaScript har tydligt fortfarande sina gränser. Om du bygger ett komplext användargränssnitt med mycket logik implementerad via JavaScript hamnar du snabbt i situationer där du i huvudsak måste skriva någon form av spaghettikod. Att hantera DOM state är trots allt svårt.

och inte bara det. Du stöter regelbundet på situationer där din DOM-traversallogik bryts om du någonsin bestämmer dig för att ombeställa din HTML-kod (eller introducera nya element).

<div> <h1>What's new?</h1> <div> <p>An interesting discussion over the future of jQuery evolved over the last days.</p> </div></div>
$('#news') .find('div') .find('p') .text('This replaces the paragraph text - hopefully')

den här koden slutar fungera om du ändrar HTML-koden så här.

<div> <h1>What's new?</h1> <p>An interesting discussion over the future of jQuery evolved over the last days.</p></div>

och detsamma skulle vara sant för vanilj JavaScript traversal tekniker.

självklart kan du skriva kod som fortfarande skulle fungera i ovanstående scenario. Men det kan då bryta under olika omständigheter. Eller du sluta med en ganska lång kedja av traversal metoder för att säkert välja vad du planerar att manipulera. Och detta blir bara svårare om du manuellt skapar eller tar bort DOM-element via jQuery.

Om du någonsin haft ett användningsfall där du behövde lägga till och ta bort element dynamiskt – låt oss säga baserat på vissa JavaScript – array som håller data-vet du smärtan som är förknippad med det när du använder jQuery eller vanilla JavaScript. Lämna ensam om du sedan vill arbeta med dessa element (t.ex. bifoga klicklyssnare eller stilar).

# ramar till undsättning!

det finns en fix för det!

JavaScript-ramar som Angular, React (Åh, det är ett bibliotek faktiskt – förlåt mig reagera folk) eller Vue till exempel.

alla dessa ramar har en grundläggande skillnad jämfört med jQuery (och vanilj JavaScript): du skriver inte kod för att manuellt navigera i DOM.

du använder en deklarativ metod istället.

vad betyder detta?

Tja, så här kan du säkert välja och manipulera HTML-innehållet från tidigare i den här artikeln – den här gången med Vue:

<div> <h1>What's new?</h1> <div> <p>{{ myText }}</p> </div></div>
new Vue({ el: '#news', data: { myText: 'This never fails to hit its target', },})

som du kan se följer Vue tydligt en annan filosofi än jQuery gör. Detsamma skulle vara sant för React och Angular förresten.

för resten av den här artikeln använder jag Vue för exemplen – helt enkelt för att den har en mycket fin syntax och det är lätt att komma igång med. Importera Vue till din webbsida och du är bra att gå.

men Angular och React följer också jämförbara tillvägagångssätt. Om du vill lära dig mer om dessa har jag användbara resurser för dig:

  • Angular-The Complete Guide
  • React-The Complete Guide
  • Angular vs React vs Vue

och naturligtvis, om du vill dyka djupare in i Vue, fick jag resurser på det också: Vue – The Complete Guide.

de fokuserar alla på att låta dig helt enkelt markera platser i DOM där innehåll ska visas. Du behöver inte beskriva vägen till den platsen-ramverket kommer att räkna ut det för dig!

# men Vue-lösningen är längre!

om du jämför jQuery-lösningen med Vue-lösningen ser du tydligt att Vue-metoden är lite längre (när det gäller skrivna kodlinjer).

men detta var ett mycket enkelt exempel! Mer komplexa exempel växer snabbt i storlek och, ännu värre, komplexitet när det gäller jQuery-kod krävs. Men inte för Vue (eller de andra ramarna).

det beror på att det allmänna tillvägagångssättet är så annorlunda. Om du bara beskriver din datastruktur, din logik och hur du ansluter dina data till DOM (din mall så att säga) behöver du inte skriva så mycket extra kod när din HTML-kod eller affärslogik blir mer komplex.

för jQuery är det dock en annan sak. Om du behöver nå element som är djupt kapslade eller om du behöver göra komplexa saker som looping genom att skapas element, slutar du snabbt med den mer komplexa (och även felbenägna) koden du såg tidigare.

detta kommer att ge:

<div> <div>Apples</div> <div>Bananas</div> <div>Milk</div></div>

de kapslade<div> elementen är klickbara ochhighlighted CSS-klassen läggs till i alla element när du klickar.

Tänk på Vue (och HTML) snippet som skulle uppnå samma:

new Vue({ el: '#output', data: { shoppingList: , },})

det är fortfarande en rad koder du behöver här men det är så mycket lättare att förstå, underhålla och redigera! Du förklarar hur din HTML-kod ska se ut i slutändan, du beskriver dina data och hanterar ditt selected – tillstånd i din JS-kod.

magin händer med hjälp av så kallade direktiv-v-for (för looping), v-on (för händelselyssning) och v-bind (för att ändra HTML – elementet) gör allt arbete här. React och Angular fick i allmänhet jämförbara lösningar, men React använder inte direktiv. Det kommer fortfarande inte att tvinga dig att manuellt skriva all kod för att välja och skapa element.

När din (frontend) webbapp växer och du bygger ännu mer komplexa användargränssnitt, kommer du att älska ett sådant deklarativt tillvägagångssätt som inte tvingar dig till oändliga, oföränderliga kedjor av css()$(...) och appendTo() samtal.

# är jQuery mindre åtminstone?

Vue erbjuder en tydligt annorlunda syntax-det gör mycket av den tunga lyftningen när det gäller DOM-åtkomst och manipulation för dig.

det måste helt klart komma till ett pris, eller hur? jQuery är verkligen mindre, eller hur?

Tja … Nej. Så är inte fallet.

Från och med mars 2018 väger jQuery 29kb minified och gzipped medan Vue kommer på 30kb minified och gzipped. vad sägs om React och Angular?

React består faktiskt av två paket: ReactDOM och React itself. Kombinerat måste du ladda ner ungefär 34kb minified + gzipped för att få det igång.

Angular är mycket större än det eftersom Angular är ett sätt större ramverk som är särskilt lämpat för stora företagsapplikationer. För sådana typer av appar kommer det att vinna mot jQuery inte på grund av dess paketstorlek men på grund av all smärta det sparar dig.

# så … använd aldrig jQuery igen?

frågan är naturligtvis om du alltid ska använda Vue, Angular eller React då. Eller finns det användningsfall där det fortfarande är vettigt att använda jQuery?

i allmänhet tror jag att jquerys tid kommer till ett slut. Åtminstone i sin nuvarande form.

Du kan fortfarande välja det för triviala fall men varför skulle du inte bara använda vanilj JavaScript för det och spara de extra 30kbs + den extra syntaxen du måste komma in i? Du kommer att bli en bättre webbutvecklare om du vet vanilla JS ändå.

jQuery ser uppenbarligen fortfarande mycket användning i många äldre webbappar och det kommer att stanna där ganska länge.

Om du behöver arbeta med sådana webbappar kommer du förmodligen inte att hitta en väg runt jQuery för nu och att lära dig det kan därför fortfarande vara något värt din tid.

många populära tredjepartspaket är fortfarande beroende av jQuery-Bootstrap, CSS-ramverket, gör det till exempel (tyvärr gör det till och med i sin senaste version – 4.x). Att behöva lägga till det extra beroendet på grund av ett sådant paket är irriterande, därför försöker jag personligen alltid ta reda på vad exakt jQuery gör för det givna paketet. När du har fått den informationen kan du bygga om funktionaliteten med vanilla JS eller någon annan ram och framgångsrikt bli av med jQuery därefter.

Lämna ett svar

Din e-postadress kommer inte publiceras.