Et objektivt blik på bibliotekskrigen: React vs Vue

Hvor kommer vi fra? Hvad er vi? Hvor er vi på vej hen?

Lad os stoppe op et øjeblik og overveje, hvor vi er. Som total boomer tvivler jeg oprigtigt på, at nogen for omkring 10 år siden kunne have forudsagt, at webudvikling ville gå så langt.

Utility desktop-applikationer hører fortiden til, fordi alt kan gøres i en browser. Faktisk skrives applikationer, der skal bruge API'er på lavere niveau, som ikke er tilgængelige i browseren, også ved hjælp af browsermotorer og -sprog, fordi det gør dem lettere at vedligeholde.

Mobilapplikationer kan nemt erstattes af værktøjer, der bruges til webudvikling - se React IndfødtNativeScript. Derudover har vi PWA, som let "efterligner" driften af mobilapplikationer. Derudover kan komponenter, der driver en applikation skrevet i Vue eller React kan nemt dele forskellige Kode elementer mellem platforme.

Vi må indrømme én ting - webapplikationer er i øjeblikket et kraftcenter, som det bliver svært at få ned på jorden. Som bruger ser jeg mig selv bruge dem praktisk talt overalt: kommunikere via Slack, bruge en kodeditor, lave præsentationer eller endda skrive en blogartikel.

Det er svært at forudsige, hvad der vil ske om et par år. WebAssembly kommer i spil, og det vil give os mulighed for at flytte applikationer, der kræver mere komplekse beregninger, ind i browserverdenen. En kendsgerning forbliver dog uændret - det er virkelig svært at finde en hindring for at bygge en applikation, som vi kun kan drømme om, ved hjælp af webteknologier.

Big bang i internet-virkeligheden

Lad os gå tilbage til fortiden et øjeblik, før de første mere betydningsfulde webframeworks dukkede op, og applikationer blev udviklet på en tvingende måde. Hver interaktiv mekaniker på en side blev håndteret manuelt og var ansvarlig for en bestemt handling.

Det bedste eksempel, der kan nævnes, er jQuery-biblioteket - på det tidspunkt en af de mest populære løsninger til håndtering af simple begivenheder. Med dets hjælp blev forskellige drop-down-menuer, overgange, animationer, regnemaskiner og lignende mekanik implementeret.

Det er værd at nævne, at man allerede dengang bemærkede problemer i mere komplekse applikationer - på steder, hvor forskellige, uafhængige dele f.eks. skulle reagere på et rigtigt klik eller på at skrive noget. De fleste applikationer havde ikke en eksplicit tilstand, men blev i stedet reddet af f.eks. elementernes attributter eller de klasser, de havde.

På det tidspunkt stod det klart, at den nuværende tilgang manglede reaktivitet - en struktureret måde for komponenter at kommunikere med hinanden og dele f.eks. deres tilstand eller forskellige hændelser, hvilket gjorde applikationer lettere at vedligeholde og gav dem mulighed for at give en god brugeroplevelse til en lav pris.

Første skridt mod velkendte rammer

Med tiden begyndte de første front-end frameworks at dukke op i horisonten med det formål at strukturere arkitekturen for mere komplekse applikationer.

Disse frameworks var hovedsageligt baseret på MVC-mønsteret - nogle foreslog en mere manuel tilgang, som Backbone.js, mens andre, som Knockout.js, koblede sig på tovejs databinding.

Alligevel kunne man føle, at det var sværere at skrive applikationen, at det krævede meget mere kodning, og at det ikke nødvendigvis gav de ønskede resultater eller kompenserede for den tid, der gik tabt i applikationsudviklingen.

Hovedårsagen til, at det var svært at finde den gyldne middelvej i JS-økosystemet, var, at det var lidt af en særhed blandt velkendte programmeringssprog der for længst har fundet deres vej.

Og jeg vil ikke her dvæle ved præcis, hvilke veje der har ledsaget udviklingen af forskellige frameworks gennem historien. Det er dog vigtigt at bemærke én ting - modningstiden for JS-økosystemet i browserne var ikke let og stod over for mange prøvelser.

Det er den eneste grund til, at vi i dag kan bygge webapplikationer og udvikle dem på en meget nem og smertefri måde.

Grundlæggende information og en lille sammenligning

I stedet for at smide om os med kød og blod, som man plejer at gøre på internettet, så lad os se på begge biblioteker, samle information om dem og sammenligne dem - både i teori og praksis.

BEMÆRK: Beskrivelsen af mekanismer, der fungerer i Vue henviser specifikt til version 2. Version 3 introducerer en masse væsentlige ændringer, men er ikke en reel konkurrent til React i øjeblikket, om ikke andet så på grund af dens modenhed - Vue 3 udgivelsesdato: 18. september 2020.

Lad os få én ting på det rene - når man graver dybere ned i begge biblioteker, kan man se, at der faktisk er flere ligheder end forskelle. Hvis man ser bort fra, hvordan man bruger bibliotekerne som sådan, så har de begge meget ensartede koncepter for, hvordan de fungerer. Begge er drevet af et lignende økosystem, og deres brug er ikke diametralt forskellig.

Djævlen ligger i detaljen - jo oftere vi bruger et værktøj, jo større ulemper ved dets forskellige løsninger opdager vi. Et godt eksempel her kan være tovejs databinding, som oftest bruges i Vue som en v-model-egenskab: Det gør ofte tingene lettere, tager sig af mange ting automatisk og kræver ikke kodning af yderligere understøttelse af ændring af værdier.

Der er dog tilfælde, hvor vi har brug for specifikt at spore et ændringsforsøg og reagere i overensstemmelse hermed, og i så fald tvinger de v-modelbaserede komponenter os ofte til at rode rundt med andre Vue mekanik såsom beregnede egenskaber, hvilket gør, at den opnåede effekt ofte ser meget værre ud end med en manuel tilgang;

Et andet interessant aspekt er JSX, som er sådan en "vagant" måde at skabelonere gengivet indhold på ved hjælp af React. Det er der forskellige meninger om i udviklermiljøet.

Ud fra mine observationer ser det ud til, at udviklere, der bruger andre miljøer end JS, f.eks. PHP eller C#, er mere tilbøjelige til at bruge skabelonvisninger på en måde, der Vue gør.

For at opsummere - skabeloner kendt fra Vue gør det muligt at definere visninger på en meget klar og elegant måde, mens React's JSX i mange tilfælde gør det muligt at opbygge dem hurtigere, skræddersyet til specifikke behov og ofte kræver mindre kode for at opbygge forskellige strukturer;

Lad os også se på økosystemerne i disse to værktøjer. I princippet kan vi sige, at de ikke adskiller sig på noget som helst. Der er en grund til, at de begge kaldes biblioteker - de giver det absolutte minimum af støtte til reaktive webapplikationer.

Mens resten, der er relateret til kommunikation med API, dataflow, UI-komponenter, der bruges omkring forskellige undersider, er de såkaldte vendors - biblioteker hentet udefra, som skal knyttes korrekt til API'en. projekt. Det er lidt ligesom Lego-verdenen: Hvis man vil bygge en sammenhængende helhed, må man sætte den sammen af enkelte, små klodser.

Denne allegori henviser til præcist vedhæftede komponenter, som er kraften i applikationer, der er skabt med React eller Vue;

En vigtig ting, især for folk, der ikke er så erfarne i JS-miljøet, er indgangsniveauet til et bestemt bibliotek. Med andre ord - værktøjets kompleksitet, der består af den direkte tid, du skal bruge på at forstå dets mekanik.

Jeg tror, at én ting skal siges helt klart her - i tilfældet med VueDet er meget enklere. Vi har tovejs databinding, vi har en elegant specificeret skabelon, der til forveksling ligner løsninger i andre sprog, f.eks. twig, og endelig - vi har ingen hovedpine forårsaget af at lære om teorier om driften af individuelle kroge og tilfælde, hvor specifikke mekanikker skal bruges.

Hvad siger statistikkerne?

Det er ikke ligefrem et godt valg at gå direkte efter mængdens stemme. Men et godt skridt i retning af at træffe en god beslutning er at analysere, hvad folk, der har interageret med disse biblioteker, siger.

Og ja... stjerner på github kan være en indikator for, hvor meget fællesskabet omkring et bestemt bibliotek er involveret i dets udvikling, hvordan det opfattes af udviklere, og om de er interesserede i, hvor det bevæger sig hen. Ingeniører, der følger et bestemt repository, får ofte meddelelser om nye udgivelser eller kodeændringer, hvilket betyder, at de har direkte kendskab til biblioteket.

Antallet af stjerner på github skal dog ikke ses som et orakel - ikke alle udviklere, der kan lide et værktøj, vil efterlade et mærke - i stedet vil jeg tage det som et tegn på ren passion, som udviklere har for et bestemt open source-projekt.

Google Trends er en velkendt tjeneste, der giver os mulighed for at studere interessen for specifikke emner over tid. Selv om det ikke er en rationel indikator for kvalitet eller brug, kan det give alle slags analyser.

Det er let at se, at forløbet af de sidste 5 år er blevet skitseret ret ens, når det drejer sig om at sammenligne de to hovedpersoner i dagens artikel. Den grundlæggende konklusion, der kan drages af diagrammet, er, at React er højere, når det gælder søgepopularitet i forhold til sin modstander.

For at gøre det klart - at ligge øverst i Google Trends betyder ikke, at et bibliotek er bedre. Det handler om publikums popularitet, som jeg nævnte før - sandsynligvis har flere mennesker hørt om dette værktøj, det kan have vakt større interesse blandt CTO'er, softwareudviklere eller folk, der bare gerne vil lære et bestemt værktøj.

Afspejler denne graf sig i virkeligheden? Til en vis grad, ja. Generelt set - blandt de adspurgte personer er der flere, der udviser en varieret og sofistikeret viden om React end Vue. Hvilke meninger kan du få ved at tale med disse mennesker? Jeg vil forsøge at skitsere dette i næste afsnit.

Staten JS  er et websted, der hvert år undersøger folk, der arbejder med JavaScript-relaterede teknologier. Målet er at indsamle oplysninger fra udviklere om, hvordan de ser på de værktøjer, de arbejder med til daglig.

Spørgsmålene dækker individuelle værktøjer til forskellige formål - f.eks. værktøjer, der bruges i front-end og back-end, men også værktøjer til test, styring af applikationsstatus osv. Hvert af disse spørgsmål er ikke et simpelt ja/nej-svar, siden stiller en række spørgsmål om selve værktøjet, interesser, erfaringer og en samlet evaluering, der kan koges ned til sætningen "Ville du bruge dette værktøj i fremtidige projekter?"

Selve sitet giver dig mulighed for at lave en masse analyser, sammenligne relevante værktøjer og nogle gange finde ud af om mindre kendte biblioteker, der begynder at klare sig godt i JS-verdenen og bliver mere og mere populære, mens de nyder godt af en høj "happiness to use"-rate. Jeg vil oprigtigt opfordre dig til at gennemse indholdet på denne side.

Lad os opsummere afsnittet med statistik. At analysere forskellige typer grafer kan ofte være en rigtig god mulighed for at sammenligne forskellige aspekter af givne emner. Det er dog vigtigt at tage højde for, at det ikke nødvendigvis er det smarteste at følge mængdens stemme. I stedet kan du træffe en informeret beslutning ved at bruge nogle af de erfaringer, du har gjort dig med analyser af diagrammer.

Bedste valg for udviklere

Tidligere nævnte jeg den lavere adgangstærskel til Vue - Det giver dig faktisk mulighed for at fokusere lidt hurtigere på den faktiske udvikling af applikationen ved at bruge værktøjet og reducere den tid, der er nødvendig for at sætte sig ind i miljøet, mekanikken og de forskellige brugssituationer, til et minimum.

Generelt er min holdning, at Vue er mere velegnet til folk, der endnu ikke har beskæftiget sig med front-end-biblioteker. Det vil helt sikkert give dig mulighed for på en mere opmuntrende måde at få tilfredsstillende resultater på kort tid.

Men lad os sige det højt - manglende kendskab til det sprog, vi bruger specifikke værktøjer på, vil skade os før eller siden. Det er et ubetydeligt element for enkle ting, men efterhånden som kompleksiteten af de oprettede applikationer stiger, bliver det mere og mere vanskeligt at bygge applikationer på en anstændig måde uden godt kendskab til JavaScript.

Jeg taler ikke om at kunne skrive nogle sofistikerede funktioner, for den del kan i høj grad erstattes af f.eks. leverandører. Jeg taler om nogle almindelige fejl, der kan begås i sproget, og at man ikke er klar over, at den forkerte opførsel ikke skyldes brugen af biblioteket, men brugen af sproget. Den mest almindelige fejl, der manifesterer sig her, er den såkaldte uforanderlighed - det vil sige kendskabet til referencemekanismen i JavaScript.

Jeg er ikke i stand til at foreslå, hvilket bibliotek der er bedst for udviklere, der er mere eller mindre fortrolige med JavaScript. Men jeg ved én ting - hvis du vil have en reel idé om, hvordan udvikling med begge værktøjer ser ud "indefra" - så prøv at skrive programmer i hver af dem. Det vil give dig en idé og give dig mulighed for at se, hvilke mekanismer der tiltaler dig mest, og hvad der er et bedre valg for dig.

Som jeg nævnte tidligere, er begge biblioteker drevet af lignende økosystemer og har samme syn på opbygning af applikationer med små komponenter. Begge biblioteker klarer sig godt - der er intet, der tyder på, at nogen af dem vil forsvinde i den nærmeste fremtid. Derfor vil jobtilbuddene i dem begge forblive på et lignende niveau.

Konklusionerne er enkle - brug det, der passer dig; saml erfaring og evaluer. Det vil hjælpe dig med at udvikle en rationel tilgang til, om det er bedre at bruge det ene eller det andet bibliotek i et bestemt projekt; prøv også at eksperimentere - intet er så lærerigt som de fejl, der er begået i fortiden.

Bedste valg til CTO

Det er ikke nogen hemmelighed, at der ikke findes en gylden middelvej, som er den bedste løsning til et bestemt projekt. Især på front-end bliver de værktøjer, der bruges til at bygge applikationer, hurtigt gamle, og det er ofte svært at finde fodfæste i de nyeste trends.

Men valget af teknologi er ikke, eller bør i hvert fald ikke være, et spørgsmål om, hvad der passer ind i de aktuelle trends. I stedet bør vi rette det mod specifikke forventninger og antagelser om den applikation, vi skal bygge. Hvert af de sammenlignede biblioteker har sine styrker og svagheder, som matchet med brugssagen vil give os mulighed for at træffe det mest fornuftige valg.

En interessant mulighed kan vise sig at være teknologisammendrag fra store virksomheder, som ofte beskriver deres use-cases, hvordan udviklingen af store applikationer foregik eller foregår, og hvilke fejl de har begået i fortiden. Måske finder vi blandt dem cases, som er særligt interessante i forbindelse med valg af bibliotek til et bestemt projekt.

De funktioner, vi bør overveje for at vælge de rigtige værktøjer til den applikation, der skal bygges, er: tiden for applikationsudvikling, hvor let det er at vedligeholdelse af applikationer, applikationens kompleksitet og udviklernes erfaring med at bruge specifikke biblioteker.

Udviklere er de mennesker, der bruger mest tid på de værktøjer, jeg sammenligner, og det er dem, der kan give de bedste råd og hjælpe dig med at træffe det bedste valg i det store sammenstød mellem biblioteker. Det er under applikationsudviklingen, at man ser de forskellige problemer, der opstår direkte af valget af teknologi, og har det bedste overblik over, hvilke ting der underminerer brugen af et bestemt værktøj til bestemte funktioner.

Som jeg nævnte tidligere - begge biblioteker ser ikke ud til at forsvinde fra markedI hvert fald ikke inden for de næste par år. I stedet for at træffe beslutninger baseret på statistikker og meninger
af forskellige mennesker fra internettet - måske er det en bedre mulighed at tale med udviklerne.

Præsenter for dem, hvad der forventes af ansøgningen, hvilken tid vi har til at levere den, og giv mulighed for en løs udveksling af meninger om, hvad de synes om begge løsninger, før vi træffer den endelige beslutning.

Konklusioner

Internetkrige er som regel - eller måske i alle tilfælde - meningsløse. Der vil altid være folk, som stædigt vil hævde, at deres valg er bedre, uden at give nogen rationelle argumenter, der bekræfter deres beslutning.

I stedet for at lade os forblænde af specifikke valg - lad os fokusere på analyse, forsøge at drage passende konklusioner og bruge dem til at justere eller forkaste en specifik løsning.

Som titlen antyder, er det ikke min hensigt at udråbe et bestemt bibliotek som en kur mod enhver smerte. I stedet præsenteres et par hypoteser, og begge bibliotekers stærke og svage sider afsløres. Jeg har givet nogle råd om, hvad man skal kigge efter, når man vælger mellem dem, så man kan træffe en klog beslutning og ikke lade sig lede af trends eller tilfældige mennesker fra internettet.

Hvert værktøj kan passe godt nok til projektets behov. Ingen af dem vil forsvinde hurtigt fra markedet i de kommende år. Begge har stærke fællesskaber og en hel del modenhed, hvilket viser os, at disse to klarer sig ganske godt.

Det endelige valg ligger i dine hænder. Men hvis du er i tvivl eller bare gerne vil drøfte din sag med The Codest, er du velkommen til at kontakte os!

Læs mere om det:

Hvorfor du (sandsynligvis) bør bruge Typescript

Hvordan dræber man ikke et projekt med dårlig kodningspraksis?

Strategier for at hente data i NextJS