Objektivní pohled na válku knihoven: React vs Vue

Odkud pocházíme? Co jsme? Kam směřujeme?

Zastavme se na chvíli a zamysleme se nad tím, kde se nacházíme. Jakožto člověk, který prožil totální boom, upřímně pochybuji, že by někdo před zhruba 10 lety dokázal předpovědět, že vývoj webových stránek by zašel tak daleko.

Užitečné desktopové aplikace jsou minulostí, protože vše lze provádět v prohlížeči. Aplikace, které potřebují používat rozhraní API nižší úrovně, jež nejsou v prohlížeči k dispozici, se ve skutečnosti také píší pomocí prohlížečových enginů a jazyků, protože se tak snáze udržují.

Mobilní aplikace lze snadno nahradit nástroji používanými pro vývoj webových aplikací - viz. React Nativní, NativeScript. Kromě toho máme k dispozici PWA, které snadno "napodobuje" fungování mobilních aplikací. Navíc komponenty, které pohánějí aplikaci napsanou v jazyce Vue nebo React můžete snadno sdílet různé kód prvky mezi platformami.

Musíme si přiznat jednu věc - webové aplikace jsou v současné době výkonným nástrojem, který bude obtížné dostat do přízemí. Jako uživatel je vidím používat prakticky všude: při komunikaci přes Slack, při práci s editorem kódu, při tvorbě prezentací nebo třeba při psaní článku na blogu.

Je těžké předvídat, co se stane za několik let. Do hry vstupuje WebAssembly, které umožní nás přesunout aplikace, které vyžadují složitější výpočty, do světa prohlížečů. Jeden fakt však zůstává neměnný - je opravdu těžké najít překážku, která by nám bránila vytvořit s využitím webových technologií takovou aplikaci, o které si můžeme nechat jen zdát.

Velký třesk v internetové realitě

K věci - vraťme se na chvíli do minulosti, než se objevily první významnější webové frameworky a aplikace se vyvíjely imperativním způsobem. Každá interaktivní mechanika na stránce se zpracovávala ručně a byla zodpovědná za konkrétní akci.

Nejlepším příkladem, který lze uvést, je knihovna jQuery - ve své době jedno z nejpopulárnějších řešení pro zpracování jednoduchých událostí. S její pomocí byly implementovány různé rozbalovací nabídky, přechody, animace, kalkulačky a podobné mechanismy.

Stojí za zmínku, že již tehdy byly zaznamenány problémy ve složitějších aplikacích - v místech, kde různé nezávislé části musely např. reagovat na správné kliknutí nebo napsání něčeho. Většina aplikací neměla explicitní stav a místo toho je zachraňovaly například atributy prvků nebo třídy, které měly.

V té době bylo zřejmé, že stávajícímu přístupu chybí reaktivita - strukturovaný způsob, jak spolu komponenty komunikují a sdílejí např. svůj stav nebo různé události, což usnadňuje údržbu aplikací a umožňuje jim poskytovat dobrý uživatelský zážitek při nízkých nákladech.

První kroky ke známým rámcům

Postupem času se na obzoru začaly objevovat první front-endové frameworky, jejichž cílem bylo strukturovat architekturu pro složitější aplikace.

Tyto frameworky vycházely především ze vzoru MVC - některé navrhovaly spíše manuální přístup, jako například Backbone.js, zatímco jiné, jako například Knockout.js, využívaly obousměrnou vazbu dat.

Přesto lze mít pocit, že psaní aplikace bylo obtížnější, vyžadovalo mnohem více kódování a nemuselo nutně přinést zamýšlené výsledky nebo kompenzovat čas ztracený při vývoji aplikace.

Hlavním důvodem, proč bylo těžké najít zlatou střední cestu v ekosystému JS, bylo to, že byla mezi známými lidmi trochu zvláštní. programovací jazyky které mají již dlouho vydlážděné cesty.

A nechci se zde zabývat tím, jaké cesty přesně provázely vývoj různých rámců v průběhu dějin. Je však důležité poznamenat jednu věc - doba zrání ekosystému JS v prohlížečích nebyla jednoduchá a čelila mnoha zkouškám.

To je jediný důvod, proč dnes můžeme vytvářet webové aplikace a vyvíjet je velmi snadno a bezbolestně.

Základní informace a drobné srovnání

Místo házení masa, jak je na internetu zvykem, se na obě knihovny podíváme, shromáždíme o nich informace a porovnáme je - teoreticky i prakticky.

POZNÁMKA: Popis mechanismů pracujících v Vue se týká konkrétně verze 2. Verze 3 přináší mnoho významných změn, ale není skutečným konkurentem verze 2. React v tuto chvíli, už jen kvůli jeho splatnosti - Vue 3 datum vydání: 18. září 2020.

Ujasněme si jednu věc - při hlubším prozkoumání obou knihoven zjistíte, že ve skutečnosti je mezi nimi více podobností než rozdílů. Pomineme-li způsob používání knihoven jako takových - obě mají velmi podobný koncept fungování. Obě jsou poháněny podobným ekosystémem a jejich použití není diametrálně odlišné.

● Ďábel se skrývá v detailech - čím častěji nástroj používáme, tím větší nevýhody jeho různých řešení zaznamenáváme. Dobrým příkladem zde může být obousměrná datová vazba, která se nejčastěji používá v oblasti Vue jako vlastnost v-modelu: často usnadňuje práci, o mnoho věcí se stará automaticky a nevyžaduje kódování další podpory pro změnu hodnot.

Existují však případy, kdy potřebujeme konkrétně sledovat pokus o změnu a podle toho reagovat, a v takovém případě nás komponenty založené na v-modelu často nutí k tomu, abychom si pohrávali s jinými komponentami. Vue mechaniky, jako je vypočtená vlastnost, takže dosažený efekt často vypadá mnohem hůře než při ručním přístupu;

● Dalším zajímavým aspektem je JSX, což je takový "vagrantní" způsob, jak šablonovat vykreslovaný obsah pomocí React. V komunitě vývojářů se názory na něj liší.

Podle mých pozorování se zdá, že vývojáři používající jiné prostředí než JS, např. PHP nebo C#, jsou více nakloněny šablonovitým pohledům způsobem, který Vue dělá.

Shrnutí - šablony známé z Vue umožňují definovat pohledy velmi přehledným a elegantním způsobem, zatímco JSX v React je umožňuje v mnoha případech vytvářet rychleji, na míru konkrétním potřebám a často vyžaduje méně kódu pro vytvoření různorodých struktur;

● Podívejme se také na ekosystémy těchto dvou nástrojů. V zásadě můžeme říci, že se v ničem neliší. Oba se z nějakého důvodu nazývají knihovny - poskytují minimum pro podporu reaktivních webových aplikací.

Zatímco zbytek, který se týká komunikace s API, toku dat, komponent uživatelského rozhraní používaných kolem různých podstránek, jsou tzv. vendory - knihovny převzaté zvenčí, které je třeba správně připojit k systému. projekt. Je to trochu jako ve světě Lega: chcete-li postavit souvislý celek - musíte ho poskládat z jednotlivých malých kostiček.

Tato alegorie odkazuje na přesně připojené komponenty, které jsou výkonem aplikací vytvořených pomocí React nebo Vue;

● Důležitá věc, zejména pro lidi, kteří nemají s prostředím JS tolik zkušeností, je úroveň vstupu do konkrétní knihovny. Jinými slovy - složitost nástroje spočívající v přímém čase, který musíte věnovat pochopení jeho mechaniky.

Myslím, že je třeba jednoznačně říci jednu věc - v případě Vue, je to mnohem jednodušší. Máme obousměrnou datovou vazbu, máme elegantně specifikovanou šablonu, která se klamavě podobá řešením v jiných jazycích, např. twigu, a konečně - nemáme bolesti hlavy způsobené učením se teorií ohledně fungování jednotlivých háčků a případů, kdy je třeba použít konkrétní mechaniku.

Co říkají statistiky?

Řídit se přímo hlasem davu není zrovna dobrá volba. Dobrým krokem k dobrému rozhodnutí je však analýza toho, co říkají lidé, kteří s těmito knihovnami přišli do styku.

A ano - hvězdičky na githubu může být ukazatelem toho, jak moc se komunita dané knihovny podílí na jejím vývoji, jak ji vnímají vývojáři a zda je zajímá, kam se ubírá. Inženýři kteří jsou hvězdičkami určitého úložiště, často dostávají oznámení o nových verzích nebo změnách kódu, což se promítá do jejich přímé znalosti knihovny.

Počet hvězdiček na githubu bychom však neměli vnímat jako orákulum - ne každý vývojář, kterému se nástroj líbí, zanechá značku - spíše bych to bral jako známku čistého nadšení vývojářů pro konkrétní open-source projekt.

Google Trends je známá služba, která umožňuje studovat zájem o konkrétní témata v čase. Přestože není racionálním ukazatelem kvality nebo využití, může poskytnout nejrůznější analýzy.

Při porovnání obou protagonistů dnešního článku lze snadno zjistit, že průběh posledních pěti let byl nastíněn dosti podobně. Základní závěr, který lze z grafu vyvodit, je, že React má vyšší popularitu ve vyhledávání ve srovnání se svým soupeřem.

Aby bylo jasno - umístění na předních místech v Google Trends neznamená, že je knihovna lepší. Jde o davovou popularitu, jak jsem již zmínil - pravděpodobně se o tomto nástroji dozvědělo více lidí, mohl vzbudit větší zájem mezi CTOs, vývojáři softwaru nebo lidé, kteří se chtějí naučit určitý nástroj.

Odráží se tento graf ve skutečnosti? Do jisté míry ano. Obecně řečeno - mezi dotázanými lidmi je více těch, kteří vykazují různě sofistikované znalosti o React než Vue. Jaké názory můžete získat při rozhovoru s těmito lidmi? Pokusím se to nastínit v dalším odstavci.

Stav JS  je web, který každoročně provádí průzkum mezi lidmi pracujícími v oblasti technologií souvisejících s JavaScript. Jejím cílem je shromáždit informace od vývojářů o tom, jak vnímají nástroje, se kterými denně pracují.

Otázky se týkají jednotlivých nástrojů pro různé účely - např. nástrojů používaných na front-endu a na back-endu, ale také nástrojů pro testování, správu stavu aplikace atd. Na každou z těchto otázek nelze odpovědět jednoduše ano/ne, stránka klade řadu otázek o samotném nástroji, zájmech, zkušenostech a celkovém hodnocení, které se shrnuje do věty "Použili byste tento nástroj v budoucích projektech?".

Samotné stránky umožňují provádět spoustu analýz, porovnávat příslušné nástroje a někdy se dozvíte i o méně známých knihovnách, kterým se ve světě JS začíná dařit, získávají popularitu a zároveň se těší vysoké míře "štěstí při používání". Upřímně vám doporučuji procházet obsah tohoto webu.

Shrňme si tento oddíl pomocí statistik. Analýza různých typů grafů může být často velmi dobrou možností pro porovnání různých aspektů daných témat. Je však třeba vzít v úvahu, že následovat hlas davu nemusí být nutně to nejchytřejší. Místo toho můžete učinit informované rozhodnutí s využitím některých poznatků získaných z analýz grafů.

Nejlepší volba pro vývojáře

Již dříve jsem se zmínil o nižším prahu pro vstup do Vue - Umožňuje totiž o něco rychleji se soustředit na samotný vývoj aplikace, používání nástroje a zkrácení času potřebného k seznámení se s prostředím, mechanikou a různými případy použití na minimum.

Obecně zastávám názor, že Vue je vhodnější pro lidi, kteří se dosud nezabývali front-endovými knihovnami. Jistě vám umožní povzbudivějším způsobem dosáhnout uspokojivých výsledků v krátkém čase.

Řekněme si to však nahlas - neznalost jazyka, v němž používáme konkrétní nástroje, nám dříve či později ublíží. U jednoduchých věcí je to zanedbatelný prvek, ale s rostoucí složitostí vytvářených aplikací bude stále obtížnější vytvářet aplikace slušným způsobem bez dobré znalosti JavaScript.

Nemám na mysli schopnost psát nějaké sofistikované funkce, protože tuto část lze z velké části nahradit např. dodavateli. Mám na mysli některé běžné chyby, kterých se lze v jazyce dopustit, a neuvědomění si, že nesprávné chování není způsobeno použitím knihovny, ale použitím jazyka. Nejčastější chybou, která se zde projevuje, je tzv. neměnnost - tedy znalost referenčního mechanismu v JavaScript.

Nejsem schopen navrhnout, která knihovna je lepší pro vývojáře více či méně obeznámené s JavaScript. Vím ale jedno - pokud chcete mít skutečnou představu o tom, jak vypadá vývoj s oběma nástroji "zevnitř" - zkuste si napsat aplikace v každém z nich. To vám dá představu, umožní vám to zjistit, který mechanismus vás oslovuje více a co je pro vás lepší volbou.

Jak jsem již zmínil - obě knihovny jsou poháněny podobnými ekosystémy a mají podobný pohled na vytváření aplikací s malými komponentami. Oběma knihovnám se daří - nic nenasvědčuje tomu, že by některá z nich měla v blízké budoucnosti zaniknout. V důsledku toho zůstanou nabídky práce v obou z nich na podobné úrovni.

Závěry jsou jednoduché - používejte to, co vám vyhovuje, sbírejte zkušenosti a vyhodnocujte. To vám pomůže vytvořit si racionální přístup k tomu, zda je v konkrétním projektu lepší použít tu či onu knihovnu; také se snažte experimentovat - nic neučí tak hluboce jako chyby učiněné v minulosti.

Nejlepší volba pro CTO

Není tajemstvím, že neexistuje zlatá střední cesta, která by byla nejlepším řešením pro konkrétní projekt. Zejména v oblasti front-endu nástroje používané pro tvorbu aplikací rychle zastarávají a často je těžké se zorientovat v nejnovějších trendech.

Výběr technologie však není, nebo by alespoň neměl být, závislý na tom, co odpovídá současným trendům. Místo toho bychom ji měli směřovat ke konkrétním očekáváním a předpokladům o aplikaci, kterou se chystáme vytvořit. Každá z porovnávaných knihoven má své silné a slabé stránky, které přizpůsobené případu použití nám umožní učinit nejrozumnější volbu.

Zajímavou možností se mohou ukázat technologická shrnutí velkých korporací, která často popisují jejich případy použití, jak probíhal nebo probíhá vývoj velkých aplikací a jaké chyby udělaly v minulosti. Možná mezi nimi najdeme případy, které jsou zajímavé zejména v souvislosti s výběrem knihovny pro konkrétní projekt.

Vlastnosti, které bychom měli zvážit, abychom vybrali správné nástroje pro vytvářenou aplikaci, jsou: doba vývoje aplikace, snadnost údržba aplikace, složitost aplikace a zkušenosti vývojářů s používáním konkrétních knihoven.

Vývojáři jsou lidé, kteří v porovnávaných nástrojích tráví nejvíce času, a právě oni vám mohou poskytnout nejlepší rady a pomoci vám vybrat si ve velkém střetu knihoven to nejlepší. Právě při vývoji aplikací vidíte různé problémy, které vyplývají přímo z volby technologie, a máte nejlepší přehled o tom, jaké věci podkopávají použití konkrétního nástroje pro konkrétní funkce.

Jak jsem se již zmínil dříve - zdá se, že obě knihovny nezmizí z webu. trh, alespoň ne v nejbližších letech. Místo rozhodování na základě statistik a názorů
různých lidí z internetu - možná lepší možností je jednoduše si promluvit s vývojáři.

Představte jim, co od aplikace očekáváme, jaký máme čas na její dodání, a umožněte jim volnou výměnu názorů na to, co si myslí o obou řešeních, než učiníme konečné rozhodnutí.

Závěry

Internetové války jsou obvykle - nebo možná v každém případě - zbytečné. Vždy se najdou lidé, kteří budou tvrdošíjně tvrdit, že jejich volba je lepší, aniž by uvedli nějaké racionální argumenty, které by jejich rozhodnutí potvrzovaly.

Namísto zaslepenosti konkrétními volbami se zaměřme na analýzu, snažme se vyvodit odpovídající závěry a využít je k úpravě nebo zamítnutí konkrétního řešení.

Jak už název napovídá - nemám v úmyslu korunovat žádnou konkrétní knihovnu jako lék na každou bolest. Namísto toho předkládám několik hypotéz a odhaluji silné a slabé stránky obou knihoven. Uvedl jsem několik rad, na co se při výběru mezi nimi zaměřit, abyste se rozhodli moudře a neřídili se trendy nebo náhodnými lidmi z internetu.

Každý nástroj může dostatečně vyhovovat potřebám projektu. Ani jeden z nich v příštích letech z trhu rychle nezmizí. Oba mají silné komunity a jsou poměrně vyspělé, což nám ukazuje, že se těmto dvěma nástrojům docela daří.

Konečná volba je ve vašich rukou. Pokud však máte jakékoli pochybnosti nebo chcete svůj případ s The Codest prodiskutovat - neváhejte nás kontaktovat!

Přečtěte si více:

Proč byste (pravděpodobně) měli používat Typescript

Jak nezničit projekt špatnými kódovacími postupy?

Strategie načítání dat v NextJS