En objektiv titt på bibliotekskriget: React vs Vue

Var kommer vi ifrån? Vad är vi för något? Vart är vi på väg?

Låt oss stanna upp ett ögonblick och fundera över var vi befinner oss. Jag är själv en av dem som har kommit längst i livet, och jag tvivlar starkt på att någon för 10 år sedan skulle ha kunnat förutse att webbutveckling skulle gå så här långt.

Utility desktop-applikationer är ett minne blott eftersom allt kan göras i en webbläsare. Faktum är att applikationer som behöver använda API:er på lägre nivå som inte är tillgängliga i webbläsaren också skrivs med hjälp av webbläsarmotorer och språk eftersom det gör dem enklare att underhålla.

Mobila applikationer kan enkelt ersättas med verktyg som används för webbutveckling - se React infödd, NativeScript. Dessutom har vi PWA, som enkelt "imiterar" driften av mobilapplikationer. Dessutom kan komponenter som driver en applikation skriven i Vue eller React enkelt kan dela med sig av olika kod element mellan plattformar.

Vi måste erkänna en sak - webbapplikationer är för närvarande ett kraftpaket som kommer att bli svårt att få ner på bottenvåningen. Som användare ser jag mig själv använda dem praktiskt taget överallt: kommunicera via Slack, använda en kodredigerare, göra presentationer eller till och med skriva en bloggartikel.

Det är svårt att förutse vad som kommer att hända om några år. WebAssembly är på väg in i bilden och det kommer att göra det möjligt för oss att flytta applikationer som kräver mer komplexa beräkningar till webbläsarvärlden. Ett faktum förblir dock oförändrat - det är verkligen svårt att hitta ett hinder för att bygga med hjälp av webbteknik en sådan applikation som vi bara kan drömma om.

Big bang i internetverkligheten

För att komma till saken - låt oss gå tillbaka till det förflutna för ett ögonblick, innan de första mer betydande webbramverken dök upp och applikationer utvecklades på ett tvingande sätt. Varje interaktiv mekanik på en sida hanterades manuellt och var ansvarig för en specifik åtgärd.

Det bästa exemplet som kan nämnas är jQuery-biblioteket - på den tiden en av de mest populära lösningarna för att hantera enkla händelser. Med dess hjälp implementerades olika rullgardinsmenyer, övergångar, animationer, kalkylatorer och liknande mekanik.

Det är värt att nämna att problem i mer komplexa applikationer uppmärksammades redan då - på platser där olika, oberoende delar var tvungna att reagera på t.ex. ett riktigt klick eller att skriva något. De flesta applikationer hade inget explicit tillstånd, utan räddades istället av t.ex. elementens attribut eller de klasser de hade.

Vid den tidpunkten stod det klart att den nuvarande metoden saknade reaktivitet - ett strukturerat sätt för komponenter att kommunicera med varandra och dela t.ex. sitt tillstånd eller olika händelser, vilket gjorde applikationer enklare att underhålla och gjorde det möjligt att ge en bra användarupplevelse till en låg kostnad.

Första stegen mot välkända ramverk

Med tiden började de första frontend-ramverken dyka upp i horisonten, med målet att strukturera arkitekturen för mer komplexa applikationer.

Dessa ramverk var huvudsakligen baserade på MVC-mönstret - vissa föreslog en mer manuell metod, som Backbone.js, medan andra, som Knockout.js, använde sig av tvåvägs databindning.

Man kan ändå tycka att det var svårare att skriva applikationen, att det krävdes mycket mer kodning och att det inte nödvändigtvis gav de resultat som var avsedda eller kompenserade för den tid som gick förlorad i applikationsutvecklingen.

Det främsta skälet till att det var svårt att hitta den gyllene medelvägen i JS-ekosystemet var att den var lite udda bland välkända programmeringsspråk som för länge sedan har fått sina stigar asfalterade.

Och jag vill inte dröja här på exakt vilka vägar som följde utvecklingen av olika ramar genom historien. Det är dock viktigt att notera en sak - mognadstiden för JS-ekosystemet i webbläsarna var inte lätt och stod inför många prövningar.

Detta är det enda skälet till att vi idag kan bygga webbapplikationer och utveckla dem på ett mycket enkelt och smärtfritt sätt.

Grundläggande information och en liten jämförelse

Istället för att kasta kött, som är brukligt på Internet, låt oss ta en titt på båda biblioteken, samla information om dem och jämföra dem - både i teorin och i praktiken.

OBS: Beskrivningen av mekanismer som fungerar i Vue hänvisar specifikt till version 2. Version 3 introducerar många viktiga förändringar, men är inte en riktig konkurrent till React just nu, om bara på grund av dess mognad - Vue 3 släppdatum: 18 september 2020.

Låt oss göra en sak klar - när du gräver djupare i båda biblioteken kan du se att det faktiskt finns fler likheter än skillnader. Om man bortser från sättet att använda biblioteken som sådana - båda har mycket liknande begrepp för hur de fungerar. Båda drivs av ett liknande ekosystem och deras användning är inte diametralt annorlunda.

● Djävulen finns i detaljerna - ju oftare vi använder ett verktyg, desto större nackdelar med dess olika lösningar märker vi. Ett bra exempel här kan vara tvåvägs databindning, som oftast används i Vue som en v-modellegenskap: den gör ofta saker enklare, tar hand om många saker automatiskt och kräver inte att man kodar in ytterligare stöd för att ändra värden.

Det finns dock fall där vi specifikt måste spåra ett förändringsförsök och reagera därefter, och i sådana fall tvingar de v-modellbaserade komponenterna oss ofta att röra runt med andra Vue mekanik, t.ex. beräkningsegenskaper, vilket gör att den uppnådda effekten ofta ser mycket sämre ut än med en manuell metod;

En annan intressant aspekt är JSX, som är ett "vagrant" sätt att skapa mallar för renderat innehåll med hjälp av React. Det har olika åsikter i utvecklargemenskapen.

Enligt mina observationer verkar det som om utvecklare som använder andra miljöer än JS, t.ex. PHP eller C#, är mer benägna att använda mallar på ett sätt som Vue gör.

Sammanfattningsvis - mallar kända från Vue gör det möjligt att definiera vyer på ett mycket tydligt och elegant sätt, medan React:s JSX gör det möjligt att bygga dem i många fall snabbare, skräddarsydda för specifika behov och ofta kräver mindre kod för att bygga olika strukturer;

● Låt oss också titta på ekosystemen i dessa två verktyg. I princip kan vi säga att de inte skiljer sig åt på något sätt. Båda kallas bibliotek av en anledning - de ger ett minimum av stöd för reaktiva webbapplikationer.

Medan resten, relaterat till kommunikation med API, dataflöde, UI-komponenter som används runt olika undersidor, är de så kallade leverantörerna - bibliotek som tas från utsidan, som måste kopplas ordentligt till projekt. Det är lite som i Lego-världen: om man vill bygga en sammanhängande helhet måste man sätta ihop den av enskilda, små klossar.

Denna allegori hänvisar till exakt bifogade komponenter, som är kraften i applikationer som skapats med React eller Vue;

● En viktig sak, särskilt för personer som inte är så erfarna i JS-miljön, är nivån på inträdet i ett visst bibliotek. Med andra ord - verktygets komplexitet, som består av den direkta tid du behöver spendera på att förstå dess mekanik.

Jag tror att en sak måste sägas otvetydigt här - i fallet med Vueär det mycket enklare. Vi har tvåvägs databindning, vi har en elegant specificerad mall som är förvillande lik lösningar i andra språk, t.ex. twig, och slutligen - vi har ingen huvudvärk som orsakas av att lära sig om teorier om hur enskilda krokar fungerar och i vilka fall specifika mekaniker måste användas.

Vad säger statistiken?

Att gå direkt på folkmassans röst är inte precis ett bra val. Ett bra steg mot att fatta ett bra beslut är dock att analysera vad människor som har interagerat med dessa bibliotek säger.

Och ja... stjärnor på github kan vara en indikator på hur mycket gemenskapen för ett visst bibliotek är involverad i dess utveckling, hur det uppfattas av utvecklare och om de är intresserade av vart det är på väg. Ingenjörer som följer ett visst arkiv får ofta meddelanden om nya versioner eller kodändringar, vilket innebär att de har direkt kunskap om biblioteket.

Antalet stjärnor på github ska dock inte ses som ett orakel - inte alla utvecklare som gillar ett verktyg kommer att lämna ett märke - utan jag skulle istället se det som ett tecken på ren passion som utvecklare har för ett visst open source-projekt.

Google Trender är en välkänd tjänst som gör det möjligt för oss att studera intresset för specifika ämnen över tid. Även om det inte är en rationell indikator på kvalitet eller användning, kan det ge alla typer av analyser.

Det är lätt att se att de senaste 5 årens utveckling har varit ganska likartad när det gäller att jämföra de två huvudpersonerna i dagens artikel. Den grundläggande slutsatsen som kan dras från diagrammet är att React är högre när det gäller sökpopularitet i förhållande till sin motståndare.

För att vara tydlig - att ligga i topp på Google Trends betyder inte att ett bibliotek är bättre. Det handlar om publikens popularitet, som jag nämnde tidigare - förmodligen har fler människor hört talas om det här verktyget, det kan ha väckt mer intresse bland CTO:er, Programvaruutvecklare eller personer som bara vill lära sig ett visst verktyg.

Stämmer detta diagram överens med verkligheten? Till viss del, ja. Generellt sett - bland de tillfrågade personerna är det fler som uppvisar olika sofistikerade kunskaper om React än Vue. Vilka åsikter kan du få genom att prata med dessa människor? Jag ska försöka beskriva detta i nästa stycke.

Staten JS  är en webbplats som varje år undersöker personer som arbetar med JavaScript-relaterad teknik. Målet är att samla in information från utvecklare om hur de ser på de verktyg som de arbetar med dagligen.

Frågorna handlar om enskilda verktyg för olika ändamål - t.ex. verktyg som används i frontend och backend, men även verktyg för testning, hantering av applikationstillstånd osv. Var och en av dessa frågor är inte ett enkelt ja/nej-svar, utan webbplatsen ställer en rad frågor om själva verktyget, intressen, erfarenheter och en övergripande utvärdering som kokar ner till meningen "Skulle du använda det här verktyget i framtida projekt?"

Webbplatsen i sig gör att du kan göra många analyser, jämföra relevanta verktyg och ibland få reda på mindre kända bibliotek som börjar göra bra ifrån sig i JS-världen, samla popularitet samtidigt som de har en hög "användarglädje". Jag uppmuntrar dig verkligen att bläddra igenom innehållet på den här webbplatsen.

Låt oss sammanfatta avsnittet med statistik. Att analysera olika typer av grafer kan ofta vara ett mycket bra alternativ för att jämföra olika aspekter av givna ämnen. Det är dock viktigt att ta hänsyn till att det inte nödvändigtvis är det smartaste att följa folkmassans röst. Istället kan du fatta ett välgrundat beslut med hjälp av några av de lärdomar du kan dra av diagramanalyser.

Bästa valet för utvecklare

Tidigare nämnde jag den lägre tröskeln för inträde till Vue - Det gör att du kan fokusera lite snabbare på den faktiska utvecklingen av applikationen, använda verktyget och minimera den tid som krävs för att bekanta dig med miljön, mekaniken och olika användningsfall.

Generellt sett är min åsikt att Vue är mer lämpad för personer som ännu inte har arbetat med front-end-bibliotek. Det kommer säkert att göra det möjligt för dig på ett mer uppmuntrande sätt att få tillfredsställande resultat på kort tid.

Men låt oss säga det högt - bristen på kunskap om det språk där vi använder specifika verktyg kommer att skada oss förr eller senare. Det är ett försumbart element för enkla saker, men när komplexiteten i de skapade applikationerna ökar kommer det att bli svårare och svårare att bygga applikationer på ett anständigt sätt utan god kunskap om JavaScript.

Jag syftar egentligen inte på att kunna skriva några sofistikerade funktioner, eftersom denna del till stor del kan ersättas av t.ex. leverantörer. Jag syftar på några vanliga misstag som kan göras i språket och att man inte är medveten om att det felaktiga beteendet inte beror på användningen av biblioteket utan på användningen av språket. Det vanligaste misstaget som manifesterar sig här är den så kallade oföränderligheten - det vill säga kunskapen om referensmekanismen i JavaScript.

Jag kan inte föreslå vilket bibliotek som är bättre för utvecklare som är mer eller mindre bekanta med JavaScript. Men jag vet en sak - om du vill ha en verklig uppfattning om hur utveckling med båda verktygen ser ut "från insidan" - försök att skriva applikationer i var och en av dem. Detta kommer att ge dig en idé, så att du kan se vilka mekanismer som tilltalar dig mer och vad som är ett bättre val för dig.

Som jag nämnde tidigare - båda biblioteken drivs av liknande ekosystem och har liknande syn på att bygga applikationer med små komponenter. Båda biblioteken går bra - det finns inget som tyder på att något av dem kommer att försvinna inom en snar framtid. Följaktligen kommer jobberbjudanden i dem båda att förbli på en liknande nivå.

Slutsatserna är enkla - använd det som passar dig, samla erfarenhet och utvärdera. Detta kommer att hjälpa dig att utveckla ett rationellt förhållningssätt till om det är bättre att använda det ena eller det andra biblioteket i ett visst projekt. Försök också att experimentera - ingenting lär ut så djupt som de misstag som gjorts i det förflutna.

Välj den bästa för CTO

Det är ingen hemlighet att det inte finns någon gyllene medelväg som är den bästa lösningen för ett visst projekt. Särskilt på frontend-sidan blir de verktyg som används för att bygga applikationer snabbt gamla och det är ofta svårt att hitta rätt i de senaste trenderna.

Valet av teknik är dock inte, eller borde åtminstone inte vara, en fråga om vad som passar in i de aktuella trenderna. Istället bör vi rikta det mot specifika förväntningar och antaganden om den applikation vi ska bygga. Var och en av de jämförda biblioteken har sina styrkor och svagheter, som matchade med användningsfallet gör att vi kan göra det mest rimliga valet.

Ett intressant alternativ kan visa sig vara tekniksammanfattningar från stora företag, som ofta beskriver sina användningsfall, hur utvecklingen av stora applikationer gick eller går och vilka misstag de gjort tidigare. Kanske hittar vi bland dem fall som är särskilt intressanta när det gäller att välja ett bibliotek för ett visst projekt.

De egenskaper som vi bör ta hänsyn till för att välja rätt verktyg för den applikation som ska byggas är: tiden för applikationsutveckling, hur lätt det är att underhåll av applikationer, applikationens komplexitet och utvecklarnas erfarenhet av att använda specifika bibliotek.

Utvecklare är de personer som tillbringar mest tid i de verktyg jag jämför och det är de som kan ge de bästa råden och hjälpa dig att göra det bästa valet i den stora krocken av bibliotek. Det är under applikationsutvecklingen som man ser de olika problem som uppstår direkt av valet av teknik, och har den bästa överblicken över vilka saker som undergräver användningen av ett visst verktyg för vissa funktioner.

Som jag nämnde tidigare - båda biblioteken verkar inte försvinna från marknadåtminstone inte under de närmaste åren. Istället för att fatta beslut baserade på statistik och åsikter
av olika människor från internet - kanske ett bättre alternativ är att helt enkelt prata med utvecklarna.

Presentera för dem vad de förväntar sig av applikationen, vilken tid vi har på oss för leverans och ge dem möjlighet till ett fritt meningsutbyte om vad de tycker om båda lösningarna innan vi fattar det slutliga beslutet.

Slutsatser

Internetkrig är vanligtvis - eller kanske i alla fall - meningslösa. Det kommer alltid att finnas människor som envist hävdar att deras val är bättre utan att ge några rationella argument som bekräftar deras beslut.

I stället för att förblindas av specifika val - låt oss fokusera på analys, försöka dra lämpliga slutsatser och använda dem för att justera eller förkasta en specifik lösning.

Precis som titeln antyder - jag har inte för avsikt att lyfta fram något särskilt bibliotek som ett botemedel mot alla problem. Istället presenteras några hypoteser och de starka och svaga sidorna hos båda biblioteken avslöjas. Jag har gett några råd om vad man bör tänka på när man väljer mellan dem för att fatta ett klokt beslut och inte låta sig vägledas av trender eller slumpmässiga personer från internet.

Varje verktyg kan passa projektets behov tillräckligt bra. Inget av dem kommer att försvinna från marknaden snabbt under de kommande åren. Båda har starka communities och en hel del mognad, vilket visar oss att dessa två klarar sig ganska bra.

Det slutliga valet ligger i dina händer. Men om du har några tvivel eller bara vill diskutera ditt fall med The Codest - tveka inte att kontakta oss!

Läs mer om detta:

Varför du (förmodligen) bör använda Typescript

Hur undviker man att döda ett projekt med dåliga kodningsrutiner?

Strategier för datahämtning i NextJS