Et objektivt blikk på bibliotekkrigen: React vs Vue

Hvor kommer vi fra? Hva er vi? Hvor er vi på vei?

La oss stoppe opp et øyeblikk og tenke over hvor vi er. Som en av dem som har vært med i boomer-generasjonen, tviler jeg oppriktig på at noen for ti år siden kunne ha forutsett at webutvikling ville gå så langt.

Utility desktop-applikasjoner hører fortiden til fordi alt kan gjøres i en nettleser. Applikasjoner som må bruke API-er på lavere nivå som ikke er tilgjengelige i nettleseren, blir også skrevet ved hjelp av nettlesermotorer og -språk fordi det gjør dem enklere å vedlikeholde.

Mobilapplikasjoner kan enkelt erstattes av verktøy som brukes til webutvikling - se React Native, NativeScript. I tillegg har vi PWA, som enkelt "imiterer" driften av mobilapplikasjoner. I tillegg kan komponenter som driver en applikasjon skrevet i Vue eller React enkelt kan dele ulike kode elementer mellom plattformer.

Vi må innrømme én ting - nettapplikasjoner er for tiden et kraftverk som det vil være vanskelig å få ned på bakkeplan. Som bruker ser jeg meg selv bruke dem praktisk talt overalt: kommunisere via Slack, bruke en kodeditor, lage presentasjoner eller til og med skrive en bloggartikkel.

Det er vanskelig å forutsi hva som vil skje om noen år. WebAssembly kommer inn i bildet, og det vil tillate oss å flytte applikasjoner som krever mer komplekse beregninger inn i nettleserverdenen. Ett faktum forblir imidlertid uendret - det er veldig vanskelig å finne et hinder for å bygge med bruk av webteknologier en slik applikasjon som vi bare kan drømme om.

Det store smellet i internettvirkeligheten

La oss gå tilbake til fortiden et øyeblikk, før de første mer betydningsfulle webrammeverkene dukket opp, og applikasjoner ble utviklet på en tvingende nødvendig måte. Hver interaktive mekaniker på en side ble håndtert manuelt og var ansvarlig for en bestemt handling.

Det beste eksemplet er jQuery-biblioteket, som på den tiden var en av de mest populære løsningene for håndtering av enkle hendelser. Med hjelp av det ble ulike rullegardinmenyer, overganger, animasjoner, kalkulatorer og lignende mekanikk implementert.

Det er verdt å nevne at man allerede den gang oppdaget problemer i mer komplekse applikasjoner - på steder der ulike, uavhengige deler for eksempel måtte reagere på et klikk eller en inntasting. De fleste applikasjoner hadde ikke en eksplisitt tilstand, og ble i stedet reddet av for eksempel attributtene til elementene eller klassene de hadde.

På den tiden var det klart at den nåværende tilnærmingen manglet reaktivitet - en strukturert måte for komponenter å kommunisere med hverandre på og dele f.eks. tilstand eller ulike hendelser, noe som gjorde applikasjonene enklere å vedlikeholde og gjorde det mulig å gi en god brukeropplevelse til en lav kostnad.

Første skritt mot velkjente rammeverk

Etter hvert begynte de første frontend-rammeverkene å dukke opp i horisonten, med sikte på å strukturere arkitekturen for mer komplekse applikasjoner.

Disse rammeverkene var hovedsakelig basert på MVC-mønsteret - noen foreslo en mer manuell tilnærming, som Backbone.js, mens andre, som Knockout.js, koblet seg til toveis databinding.

Likevel kan man føle at det var vanskeligere å skrive applikasjonen, at det krevde mye mer koding, og at det ikke nødvendigvis ga de resultatene som var tiltenkt eller kompenserte for den tiden som gikk tapt i applikasjonsutviklingen.

Hovedgrunnen til at det var vanskelig å finne den gylne middelvei i JS-økosystemet, var at den var litt av en raritet blant velkjente programmeringsspråk som for lengst har funnet sin vei.

Og jeg vil ikke dvele her på nøyaktig hvilke stier som fulgte utviklingen av forskjellige rammer gjennom historien. Det er imidlertid viktig å merke seg en ting - modningstiden for JS-økosystemet i nettleserne var ikke lett og sto overfor mange prøvelser.

Dette er den eneste grunnen til at vi i dag kan bygge webapplikasjoner og utvikle dem på en veldig enkel og smertefri måte.

Grunnleggende informasjon og en liten sammenligning

I stedet for å kaste med kjøtt, slik det er vanlig på Internett, la oss ta en titt på begge bibliotekene, samle informasjon om dem og sammenligne dem - både i teori og praksis.

MERK: Beskrivelsen av mekanismer som fungerer i Vue refererer spesifikt til versjon 2. Versjon 3 introduserer mange viktige endringer, men er ikke en reell konkurrent til React for øyeblikket, om ikke bare på grunn av modenhet - Vue 3 utgivelsesdato: 18. september 2020.

La oss få én ting på det rene - når du graver dypere i begge bibliotekene, ser du at det faktisk er flere likheter enn forskjeller. Hvis vi ser bort fra hvordan bibliotekene brukes som sådan - begge har veldig like konsepter for hvordan de fungerer. Begge er drevet av et lignende økosystem, og bruken av dem er ikke diametralt forskjellig.

Djevelen ligger i detaljene - jo oftere vi bruker et verktøy, desto større ulemper med de ulike løsningene legger vi merke til. Et godt eksempel her kan være toveis databinding, som oftest brukes i Vue som en v-modellegenskap: Den gjør ofte ting enklere, tar seg av mange ting automatisk og krever ikke at man koder inn ekstra støtte for endring av verdier.

Det finnes imidlertid tilfeller der vi spesifikt må spore et endringsforsøk og reagere deretter, og i slike tilfeller tvinger de v-modellbaserte komponentene oss ofte til å rote med andre Vue mekanikk som beregnede egenskaper, noe som gjør at den oppnådde effekten ofte ser mye dårligere ut enn med en manuell tilnærming;

Et annet interessant aspekt er JSX, som er en "vagant" måte å lage mal for gjengitt innhold ved hjelp av React. Det er ulike meninger om dette i utviklermiljøet.

Ut fra mine observasjoner ser det ut til at utviklere som bruker andre miljøer enn JS, f.eks. PHP eller C#, er mer tilbøyelige til å bruke malvisninger på en måte som Vue gjør det.

For å oppsummere - maler kjent fra Vue gjør det mulig å definere visninger på en svært tydelig og elegant måte, mens Reacts JSX gjør det mulig å bygge dem i mange tilfeller raskere, skreddersydd til spesifikke behov og krever ofte mindre kode for å bygge ulike strukturer;

La oss også se på økosystemene til disse to verktøyene. I prinsippet kan vi si at de ikke skiller seg fra hverandre på noe punkt. Det er en grunn til at begge kalles biblioteker - de gir et minimum av støtte for reaktive webapplikasjoner.

Resten, som er relatert til kommunikasjon med API, dataflyt, UI-komponenter som brukes rundt ulike undersider, er såkalte vendors - biblioteker som hentes utenfra, og som må kobles riktig til prosjekt. Det er litt som i Lego-verdenen: Hvis du vil bygge en sammenhengende helhet, må du sette den sammen av små, individuelle klosser.

Denne allegorien refererer til nettopp vedlagte komponenter, som er kraften i applikasjoner som er laget med React eller Vue;

En viktig ting, spesielt for folk som ikke har så mye erfaring med JS-miljøet, er hvor lett det er å komme inn i et bestemt bibliotek. Med andre ord - verktøyets kompleksitet, som består av den direkte tiden du trenger å bruke på å forstå mekanikken.

Jeg tror én ting må slås fast her - når det gjelder Vueer det mye enklere. Vi har toveis databinding, vi har en elegant spesifisert mal som er til forveksling lik løsninger i andre språk, f.eks. twig, og til slutt - vi slipper å lære oss teorier om hvordan de enkelte krokene fungerer og i hvilke tilfeller spesifikke mekanikker må brukes.

Hva sier statistikken?

Det er ikke akkurat et godt valg å følge folkemeningen. Et godt skritt på veien mot å ta en god beslutning er imidlertid å analysere hva folk som har hatt kontakt med disse bibliotekene, sier.

Og ja... stjerner på github kan være en indikator på hvor mye fellesskapet for et bestemt bibliotek er involvert i utviklingen av det, hvordan det oppfattes av utviklere og om de er interessert i hvor det er på vei. Ingeniører som følger et bestemt repository, får ofte varsler om nye utgivelser eller kodeendringer, noe som betyr at de har direkte kjennskap til biblioteket.

Antall stjerner på github bør imidlertid ikke ses på som et orakel - ikke alle utviklere som liker et verktøy, vil legge igjen et merke - i stedet vil jeg ta det som et tegn på ren lidenskap som utviklere har for et bestemt åpen kildekode-prosjekt.

Google Trends er en velkjent tjeneste som gjør det mulig å studere interessen for bestemte temaer over tid. Selv om det ikke er en rasjonell indikator på kvalitet eller bruk, kan det gi alle slags analyser.

Det er lett å se at forløpet de siste fem årene har vært ganske likt når det gjelder sammenligningen av de to hovedpersonene i dagens artikkel. Den grunnleggende konklusjonen som kan trekkes fra diagrammet, er at React er høyere når det gjelder søkepopularitet i forhold til motstanderen.

For å gjøre det klart - å ligge på topp i Google Trends betyr ikke at et bibliotek er bedre. Det handler om popularitet, som jeg nevnte tidligere - sannsynligvis har flere hørt om dette verktøyet, det kan ha vekket mer interesse blant CTO-er, programvareutviklere eller folk som bare ønsker å lære seg et bestemt verktøy.

Gjenspeiles denne grafen i virkeligheten? Til en viss grad, ja. Generelt sett - blant de spurte i undersøkelsen er det flere som har mer eller mindre sofistikerte kunnskaper om React enn Vue. Hvilke meninger kan du få ved å snakke med disse menneskene? Jeg vil prøve å skissere dette i neste avsnitt.

Staten JS  er et nettsted som hvert år gjennomfører spørreundersøkelser blant folk som jobber med JavaScript-relatert teknologi. Målet er å samle informasjon fra utviklere om hvordan de ser på verktøyene de jobber med til daglig.

Spørsmålene dekker individuelle verktøy for ulike formål - f.eks. verktøy som brukes på front-end og back-end, men også verktøy for testing, applikasjonstilstandsstyring osv. Hvert av disse spørsmålene er ikke et enkelt ja/nei-svar, nettstedet stiller en rekke spørsmål om selve verktøyet, interesser, erfaringer og en samlet evaluering som koker ned til setningen "Vil du bruke dette verktøyet i fremtidige prosjekter?"

På selve nettstedet kan du gjøre mange analyser, sammenligne relevante verktøy og noen ganger finne ut om mindre kjente biblioteker som begynner å gjøre det bra i JS-verdenen, og som blir stadig mer populære samtidig som de har en høy "happiness to use"-rate. Jeg oppfordrer deg til å bla gjennom innholdet på dette nettstedet.

La oss oppsummere avsnittet med statistikk. Å analysere ulike typer grafer kan ofte være et svært godt alternativ for å sammenligne ulike aspekter ved et gitt tema. Det er imidlertid viktig å være klar over at det ikke nødvendigvis er det smarteste å følge folk flest. I stedet kan du ta en informert beslutning ved å bruke noen av lærdommene fra diagramanalyser.

Beste valg for utviklere

Tidligere nevnte jeg den lavere terskelen for å komme inn på Vue - Det gjør at du kan fokusere litt raskere på selve utviklingen av applikasjonen, bruke verktøyet og redusere tiden som trengs for å bli kjent med miljøet, mekanikken og ulike brukstilfeller til et minimum.

Generelt er jeg av den oppfatning at Vue er mer egnet for personer som ennå ikke har jobbet med frontend-biblioteker. Det vil helt sikkert gi deg en mer oppmuntrende måte å få tilfredsstillende resultater på kort tid.

La oss imidlertid si det høyt - mangelen på kunnskap om språket der vi bruker spesifikke verktøy vil skade oss før eller senere. Det er et ubetydelig element for enkle ting, men etter hvert som kompleksiteten i de opprettede applikasjonene øker, vil det bli vanskeligere og vanskeligere å bygge applikasjoner på en anstendig måte uten god kunnskap om JavaScript.

Jeg sikter egentlig ikke til det å kunne skrive noen sofistikerte funksjoner, for denne delen kan i stor grad erstattes av f.eks. leverandører. Jeg sikter til noen vanlige feil som kan gjøres i språket, og at man ikke er klar over at den feilaktige oppførselen ikke skyldes bruken av biblioteket, men bruken av språket. Den vanligste feilen som manifesterer seg her, er den såkalte uforanderligheten - det vil si kunnskapen om referansemekanismen i JavaScript.

Jeg kan ikke foreslå hvilket bibliotek som er best for utviklere som er mer eller mindre kjent med JavaScript. Men én ting vet jeg - hvis du vil få et inntrykk av hvordan utvikling med begge verktøyene ser ut "fra innsiden", bør du prøve å skrive programmer i hvert av dem. Dette vil gi deg en idé, slik at du kan se hvilke mekanismer som appellerer mer til deg og hva som er et bedre valg for deg.

Som jeg nevnte tidligere - begge bibliotekene drives av lignende økosystemer, og har lignende syn på å bygge applikasjoner med små komponenter. Begge bibliotekene gjør det bra - det er ingen indikasjoner på at noen av dem vil forsvinne i nær fremtid. Følgelig vil jobbtilbudene i begge forbli på et lignende nivå.

Konklusjonen er enkel - bruk det som passer deg, samle erfaring og evaluer. Dette vil hjelpe deg med å utvikle en rasjonell tilnærming til om det er bedre å bruke det ene eller det andre biblioteket i et bestemt prosjekt. Prøv også å eksperimentere - ingenting lærer deg så mye som feilene du har gjort tidligere.

Beste valg for CTO

Det er ingen hemmelighet at det ikke finnes noen gylden middelvei som er den beste løsningen for et bestemt prosjekt. Spesielt på frontend-siden blir verktøyene som brukes til å bygge applikasjoner, fort gamle, og det er ofte vanskelig å finne seg til rette i de nyeste trendene.

Valg av teknologi er imidlertid ikke, eller bør i det minste ikke være, et spørsmål om hva som passer inn i dagens trender. I stedet bør vi rette det mot spesifikke forventninger og antakelser om applikasjonen vi skal bygge. Hvert av de sammenlignede bibliotekene har sine styrker og svakheter, som sammen med bruksområdet vil gjøre det mulig for oss å ta det mest fornuftige valget.

Et interessant alternativ kan vise seg å være teknologisammendrag fra store selskaper, som ofte beskriver deres use-cases, hvordan utviklingen av store applikasjoner gikk eller går, og hvilke feil de har gjort tidligere. Kanskje finner vi blant dem tilfeller som er spesielt interessante i forbindelse med valg av bibliotek for et bestemt prosjekt.

De funksjonene vi bør ta hensyn til for å velge riktig verktøy for applikasjonen som skal bygges, er: tiden det tar å utvikle applikasjonen, hvor enkelt det er å vedlikehold av applikasjoner, kompleksiteten i applikasjonen og utviklernes erfaring med bruk av spesifikke biblioteker.

Det er utviklerne som tilbringer mest tid i de verktøyene jeg sammenligner, og det er de som kan gi de beste rådene og hjelpe deg med å ta det beste valget i den store mengden av biblioteker. Det er under applikasjonsutviklingen at man ser de ulike problemene som oppstår direkte som følge av valg av teknologi, og har best oversikt over hvilke ting som undergraver bruken av et bestemt verktøy for bestemte funksjoner.

Som jeg nevnte tidligere - begge bibliotekene ser ikke ut til å forsvinne fra markedi hvert fall ikke de nærmeste årene. I stedet for å ta beslutninger basert på statistikk og meninger
av ulike personer fra internett - kanskje et bedre alternativ er å bare snakke med utviklerne.

Presenter for dem hva som forventes av søknaden, hvor lang tid vi har på oss til å levere den, og gi dem mulighet til å utveksle meninger om hva de synes om begge løsningene før vi tar den endelige avgjørelsen.

Konklusjoner

Internett-kriger er som regel - eller kanskje i alle tilfeller - meningsløse. Det vil alltid være noen som hardnakket vil hevde at deres valg er bedre, uten å komme med noen rasjonelle argumenter som bekrefter deres beslutning.

I stedet for å la oss blinde av spesifikke valg - la oss fokusere på analyse, prøve å trekke passende konklusjoner og bruke dem til å justere eller forkaste en spesifikk løsning.

Akkurat som tittelen antyder - jeg har ikke til hensikt å utpeke noe bestemt bibliotek som en kur mot alle smerter. I stedet presenteres noen hypoteser, og de sterke og svake sidene ved begge bibliotekene avdekkes. Jeg har også gitt noen råd om hva man bør se etter når man skal velge mellom dem, slik at man kan ta en klok beslutning og ikke la seg lede av trender eller tilfeldige personer på internett.

Hvert verktøy kan passe godt nok til prosjektets behov. Ingen av dem vil forsvinne fra markedet i løpet av de kommende årene. Begge har sterke miljøer og en viss modenhet, noe som viser oss at de gjør det ganske bra.

Det endelige valget ligger i dine hender. Men hvis du er i tvil eller bare ønsker å diskutere saken din med The Codest, er du velkommen til å kontakte oss!

Les mer om dette:

Derfor bør du (sannsynligvis) bruke Typescript

Hvordan unngår man å drepe et prosjekt med dårlig kodingspraksis?

Strategier for datahenting i NextJS