# hvorfor diskuterer vi endda fremtiden for JK?

gå ikke glip af videoen over artiklen!

fordi du stadig kører størstedelen af frontend – logikken! Det driver omkring 70% af de øverste hjemmesider og 20% af hele internettet (kilde). Det er enormt!

men dette gør spørgsmålet om dets fremtid endnu fremmed.

har problemer. Det er overalt, og det er ikke rigtig fremtidssikret. Det var et fantastisk værktøj, da det blev frigivet tilbage i 2006, men de kerneproblemer, det fik fast på det tidspunkt, er ikke længere problemer. I stedet kan du nu løbe ind i flere problemer, når du bruger JK.

for at forstå dette, lad os overveje de problemer, der blev rettet tilbage i 2006.

JavaScript var slags brudt, og bro.sere implementerede det meget forskelligt

dette var en af de vigtigste ting, som jespery hjalp med. Pludselig havde du en brugervenlig API, som gjorde det muligt for dig at manipulere DOM. Og endnu bedre end det: den samme API fungerede på tværs af alle større bro. sere!

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

JavaScript og internettet som helhed var langt mindre modne

jforespørgsel tillod udviklere at simpelthen” gøre mere ” på nettet – på frontend for at være præcis. Det var lettere at oprette engagerende brugergrænseflader (som du har brug for JavaScript til), fordi du kunne bruge en veldokumenteret API. Animering af elementer, Tilføjelse og fjernelse af indhold, ændring af stilarter og genbestilling af varer var betydeligt lettere at opnå end med vanilla JavaScript. en kraftfuld og alligevel tilgængelig API, som gjorde det nemt at sende baggrundsanmodninger. Dette er en kerne byggesten af JavaScript-drevne UI ‘ er, da du ikke behøver at indlæse en ny side ved hver brugerhandling og kan indlæse eller manipulere serversidedata bag kulisserne.

    Lær Vue.js

    Vue.js gør opbygning af reaktive hjemmesider enkel. En dejlig syntaks + kraftfulde funktioner-det er ikke den værste pakke, du kunne få.

    Lær React

    React er et godt alternativ til Vue.js. Det er ekstremt populært, og du bør absolut ikke gå glip af det!

    Lær Angular

    Angular startede det hele! Lær de rammer, der er mor til React.js og Vue!

# Hvad har ændret sig?

de problemer, der er rettet af , er ikke længere problemer.

JavaScript modnet, bro. ser Kompatibilitet fik måde bedre. Vi har et levende frontend-udviklingsøkosystem med tusindvis af pakker og værktøjer.

dette betyder ikke, at alt er godt, men de kerneproblemer, der blev rettet af jespership, eksisterer ikke længere.

i stedet er det et værktøj, der ofte (ikke altid selvfølgelig) bruges af mindre erfarne internetudviklere, der aldrig skiftede til vanilla JavaScript eller rammer som Angular eller React.

og det er vigtigt at forstå forresten: vi taler ikke kun om jespery vs Angular. Vanilla JavaScript er et rigtigt alternativ!mens DOM traversal og manipulation var langt vanskeligere i 2006, fik vi mange funktionaliteter som f.eks. Disse ting fungerer, og de fungerer endda på tværs af brugere.

Hvis du har mulighed for at bruge vanilje JavaScript i stedet for at opnå stort set det samme med Jespers, er det naturligvis bedre at bruge vanilla-indstillingen. Du gemmer den ekstra pakke overførsel, og du behøver ikke at lære en ekstra syntaks.

# det er ikke bare vanilje JavaScript…

det er dog ikke bare vanilje JavaScript. Vi har simpelthen fået bedre alternativer i disse dage.

Vanilla JavaScript har tydeligvis stadig sine grænser. Hvis du bygger et komplekst brugergrænseflade med en masse logik implementeret via JavaScript, ender du hurtigt i situationer, hvor du i det væsentlige skal skrive en slags spaghetti-kode. Det er trods alt vanskeligt at styre DOM-staten.

og ikke bare det. Du løber regelmæssigt ind i situationer, hvor din DOM-traversal-logik går i stykker, hvis du nogensinde beslutter at ombestille din HTML-kode (eller introducere nye elementer).

<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')

denne kode stopper med at fungere, hvis du ændrer HTML-koden som denne.

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

og det samme ville være tilfældet for vanilje JavaScript traversal teknikker.

det er klart, at du kan skrive kode, der stadig fungerer i ovenstående scenarie. Men det kan så bryde under forskellige omstændigheder. Eller du ender med en ganske lang kæde af traversal metoder til sikkert at vælge, hvad du planlægger at manipulere. Og dette bliver kun vanskeligere, hvis du manuelt opretter eller fjerner DOM-elementer via Jespers.

Hvis du nogensinde har haft en brugssag, hvor du har brug for at tilføje og fjerne elementer dynamisk-lad os sige baseret på nogle JavaScript – array, der holder data – kender du den smerte, der er forbundet med det, når du bruger JavaScript. Lad være, hvis du derefter vil arbejde med disse elementer (f.eks.

# rammer til undsætning!

Der er en løsning til det!JavaScript rammer som Angular, React (Åh, det er et bibliotek faktisk – tilgiv mig React folk) eller Vue for eksempel.

alle disse rammer har en grundlæggende forskel i forhold til jekry (og vanilje JavaScript): du skriver ikke kode for manuelt at navigere i DOM.

du bruger en deklarativ tilgang i stedet.

hvad betyder det?

Nå, her er hvordan du sikkert kunne vælge og manipulere HTML – indholdet fra tidligere i denne artikel-denne gang ved hjælp af 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ølger Vue klart en anden filosofi end JK gør. Det samme ville være tilfældet for React og Angular forresten.

i resten af denne artikel bruger jeg Vue til eksemplerne – simpelthen fordi den har en meget flot syntaks, og det er nemt at komme i gang med. Importer Vue til din hjemmeside, og du er god til at gå.

men Angular og React følger også sammenlignelige tilgange. Hvis du vil lære mere om disse, har jeg nyttige ressourcer til dig:

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

og selvfølgelig, hvis du vil dykke dybere ned i Vue, fik jeg også ressourcer på det: Vue – The Complete Guide.

de fokuserer alle på at give dig mulighed for blot at markere steder i DOM, hvor indhold skal vises. Du behøver ikke at beskrive stien til det sted – rammen vil finde det for dig!

# men Vue-løsningen er længere!

Hvis du sammenligner jfor-løsningen med Vue-løsningen, ser du tydeligt, at Vue-tilgangen er lidt længere (med hensyn til kodelinjer skrevet).

men dette var et meget simpelt eksempel! Mere komplekse eksempler vokser hurtigt i størrelse og, endnu værre, kompleksitet, når det kommer til krævede kode. Men ikke for Vue (eller de andre rammer).

det er fordi den generelle tilgang er så anderledes. Hvis du bare beskriver din datastruktur, din logik og hvordan du forbinder dine data til DOM (din skabelon så at sige), behøver du ikke skrive så meget ekstra kode, når din HTML-kode eller forretningslogik bliver mere kompleks.

det er dog en anden ting. Hvis du har brug for at nå elementer, der er dybt indlejret, eller hvis du har brug for at gøre komplekse ting som at løbe igennem til-være-oprettede elementer, ender du hurtigt med den mere komplekse (og også fejlbehæftede) kode, du så tidligere.

dette vil give:

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

de indlejrede<div> elementer kan klikkes, oghighlighted CSS-klasse tilføjes til ethvert element ved at klikke.

overvej Vue (og HTML) uddrag, der ville opnå det samme:

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

det er stadig en række koder, du har brug for her, men det er så meget lettere at forstå, vedligeholde og redigere! Du erklærer, hvordan din HTML-kode skal se ud i sidste ende, du beskriver dine data og administrerer din selected tilstand i din JS-kode.

magien sker ved hjælp af såkaldte direktiver-v-for (til looping), v-on (til hændelseslytning) og v-bind (til ændring af HTML – elementet) gør alt arbejdet her. React og Angular fik generelt sammenlignelige løsninger, selvom React ikke bruger direktiver. Det vil stadig ikke tvinge dig til manuelt at skrive al koden til valg og oprettelse af elementer.

Når din (frontend) internetapp vokser, og du bygger endnu mere komplekse UI ‘ er, vil du elske en sådan deklarativ tilgang, som ikke tvinger dig til uendelige, uopnåelige kæder af css()$(...)og appendTo() opkald.

# er det i det mindste mindre?

Vue tilbyder en markant anderledes syntaks – det gør meget af det tunge løft med hensyn til DOM-adgang og manipulation for dig.

det skal helt klart komme til en pris,ikke? JFK er jo mindre, ikke?

Nå … nej. Det er ikke tilfældet.

fra marts 2018 vejer den 29kb minified og gcipped, mens Vue kommer på 30KB minified og gcipped. hvad med React og Angular?

React består faktisk af to pakker: ReactDOM og React selv. Kombineret, er du nødt til at hente nogenlunde 34kb minified + gcipped at få det op at køre.vinkel er langt større end den, da vinkel er en langt større ramme, der er specielt velegnet til store virksomhedsapplikationer. For sådanne typer apps vinder det mod jforespørgsel ikke på grund af dets pakkestørrelse, men på grund af al den smerte, det sparer dig.

# så … brug aldrig JK igen?

spørgsmålet er nu selvfølgelig, om du altid skal bruge Vue, Angular eller React da. Eller er der brugssager, hvor det stadig giver mening at bruge jfr?

generelt tror jeg, at Jespers tid er ved at ende. I hvert fald i sin nuværende form.

Du kan stadig vælge det til trivielle sager, men hvorfor ville du ikke bare bruge vanilje JavaScript til det og gemme de ekstra 30 kg + den ekstra syntaks, du skal komme ind på? Du bliver en bedre udvikler, hvis du kender vanilla JS alligevel.det er klart, at der stadig er meget brug i mange ældre apps, og det vil blive der i nogen tid.

Hvis du har brug for at arbejde på sådanne internet-apps, vil du sandsynligvis ikke finde en vej rundt i jesperry for nu og lære det kan derfor stadig være noget værd at bruge tid.

mange populære tredjepartspakker er også stadig afhængige af CSS-rammen (desværre gør det endda i sin seneste version – 4.h). At skulle tilføje den ekstra afhængighed på grund af en sådan pakke er irriterende, derfor prøver jeg personligt altid at finde ud af, hvad der præcist gør for den givne pakke. Når du har fået det stykke information, kan du genopbygge funktionaliteten med vanilla JS eller en anden ramme og med succes slippe af med Jespers.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.