Hlutlæg yfirsýn yfir bókasafnskríginn: React vs Vue

Hvaðan komum við? Hvað erum við? hvert erum við að fara?

Við skulum staldra við í smá stund og íhuga hvar við stöndum. Sem algjörur bumerang-kynslóðarfulltrúi efast ég einlæglega um að fyrir um tíu árum hefði nokkur getað spáð því að vefþróun Myndi fara svona langt.

Verkfæradiskforrit eru orðin hlutur fortíðarinnar því allt er hægt að gera í vafranum. Reyndar eru forrit sem þurfa að nota lægri stigs API sem ekki eru í boði í vafranum einnig skrifuð með vafravélum og forritunarmálum, því það auðveldar viðhald þeirra.

Farsímaforrit er hægt að skipta auðveldlega út fyrir verkfæri sem notuð eru til vefur þróun – sjá React Innfæddur, NativeScript. Auk þess höfum við PWA, sem auðveldlega “hermir eftir” starfsemi farsímaforrita. Auk þess eru íhlutir sem knýja forrit skrifað í Vue eða React getur auðveldlega deilt ýmsu kóði þættir milli vettvanga.

Við verðum að viðurkenna eitt – vefumsóknir eru nú orkugjafar sem erfitt verður að fella aftur niður á jarðhæð. Sem notandi sé ég sjálfan mig nota þær nánast alls staðar: til að eiga samskipti í Slack, nota kóðaritil, búa til kynningar eða jafnvel skrifa bloggfærslu.

Það er erfitt að spá fyrir um hvað mun gerast eftir nokkur ár. WebAssembly er að koma inn í leikinn og það mun gera kleift okkur að færa forrit sem krefjast flóknari útreikninga yfir í vafrann. Eitt atriði er þó óbreytt – það er mjög erfitt að finna hindrun sem, með því að nota vef­tækni, hindri okkur í að byggja forrit sem við getum aðeins dreymt um.

Stóri banginn í netveruleikanum

Til málsins – skulum við fara stutta stund aftur til fortíðar, áður en fyrstu marktæku vefgrindverkin komu fram og forrit voru þróuð á skipanalegum hátt. Hver gagnvirk eining á síðu var meðhöndluð handvirkt og bar ábyrgð á tilteknum aðgerðum.

Besta dæmið sem nefna má er jQuery-bókasafnið – á þeim tíma eitt af vinsælustu lausnum til að meðhöndla einföld atburði. Með því var hægt að innleiða ýmsar fellivalmyndir, umbreytingar, hreyfimyndir, reiknivélar og svipaðar virkni.

Það er þess virði að nefna að vandamál í flóknari forritum komu fram þá þegar – á stöðum þar sem mismunandi, sjálfstæðir hlutar þurftu til dæmis að react til að ná réttu smell eða til að skrifa eitthvað. Flest forrit höfðu ekki skýrt ástand og voru í staðinn bjargað með til dæmis eiginleikum þátta eða þeim flokkum sem þau tilheyrðu.

Á þeim tíma var ljóst að núverandi nálgun skorti reactivity – uppbyggða leið fyrir íhluti til að eiga samskipti sín á milli og deila, til dæmis ástandi sínu eða mismunandi atburðum, sem gerði forritum auðveldara að viðhalda og leyfði þeim að bjóða upp á góða notendaupplifun á lágu verði.

Fyrstu skrefin í átt að vel þekktum rammaskipulögum

Með tímanum byrjuðu fyrstu framsíðufrámvæmin að birtast á sjóndeildarhringnum, með það að markmiði að móta arkitektúrinn fyrir flóknari forrit.

Þessir rammar voru aðallega byggðir á MVC-mynstrinu – sumir lögðu til meira handvirka nálgun, eins og Backbone.js, á meðan aðrir, eins og Knockout.js, tengdust tvíátta gögn bindandi.

Þrátt fyrir það mátti finna að ritun forritsins var erfiðari, krafðist mun meiri kóðunar og skilaði ekki endilega þeim niðurstöðum sem ætlast var til né bættist upp fyrir þann tíma sem fór í þróun forritsins.

Aðalástæðan fyrir því að finna gullna meðaltalið í JS Það sem var erfitt við vistkerfið var að það var dálítið sérkennilegt meðal vel þekktra forritunarmál sem hafa lengi haft malbikaða vegi.

Og ég vil ekki dvelja hér við nákvæmlega hvaða leiðir fylgdu þróun ýmissa ramma í gegnum söguna. Hins vegar er mikilvægt að taka eina hlut: þroskatími JS-vistkerfisins í vafra var ekki auðveldur og stóð frammi fyrir mörgum prófraunum.

Þetta er eina ástæðan fyrir því að við getum í dag smíðað vefumsóknir og þróað þær á mjög auðveldan og sársaukalausan hátt.

Grunnupplýsingar og smávægileg samanburður

Í stað þess að kasta steik, eins og venjulega er gert á netinu, skulum við skoða báðar bókasöfnin, safna upplýsingum um þau og bera þau saman – bæði í kenningu og í framkvæmd.

ATHUGIÐ: Lýsing á vélbúnaði sem starfar í Vue Vísar sérstaklega til útgáfu 2. Útgáfa 3 kynnir margar verulegar breytingar, en er ekki raunverulegur keppinautur við React á þessari stundu, ef ekki nema vegna þroska þess – útgáfudagur Vue 3: 18. september 2020.

Látum okkur gera eitt ljóst – þegar þú kíkir nánar á báðar bókasöfnin sérðu að í raun eru fleiri líkindi en munir. Séu aðferðir við notkun bókasafnanna sjálfra teknar til hliðar – hafa þau bæði mjög svipuð hugtök um hvernig þau virka. Bæði eru knúin áfram af svipuðu vistkerfi og notkun þeirra er ekki gjörólík.

● Djöfullinn býr í smáatriðunum – því oftar sem við notum tól, því meira tökum við eftir ókostum hinna ýmsu lausna þess. Gott dæmi um þetta er tvíátta gagnatenging, sem er oftast notuð í Vue sem eiginleiki í V-líkaninu: það gerir hlutina oft auðveldari, sér um margt sjálfkrafa og krefst ekki kóðunar á viðbótar stuðningi við breytingar á gildum.

Hins vegar eru til tilfelli þar sem við þurfum að fylgjast sérstaklega með tilraun til breytinga og react í samræmi við það, sem oft neyðir okkur til að fikta við aðra Vue eiginleikar eins og reiknaður eiginleiki, sem láta áhrifin sem náðst er oft líta mun verr út en með handvirkri nálgun;

● Annar áhugaverður þáttur er JSX, sem er svo “vandrænn” háttur til að sniðmóta birta efni með React. Það eru mismunandi skoðanir í forritarsamfélaginu.

Úr mínum athugunum virðist sem forritarar sem nota umhverfi annað en JS, t.d. PHP eða C#, eru líklegri til að tileinka sér sniðmátasýn á þann hátt að Vue gerir.

Til að draga saman – sniðmát sem þekkt eru frá Vue leyfir að skilgreina sýnir á mjög skýran og fágaðan hátt, á meðan JSX hjá React gerir kleift að byggja þær í mörgum tilfellum hraðar, sérsniðnar að sérstökum þörfum og krefst oft minni kóða til að byggja upp fjölbreyttar uppbyggingar;

● Skoðum einnig vistkerfi þessara tveggja verkfæra. Í meginatriðum má segja að þau séu engu öðruvísi. Bæði kallast bókasöfn af ástæðu – þau bjóða upp á hið allra lágmarks stuðning við reactive vefumsóknir.

Á meðan restin, sem tengist samskiptum við forritaskil, gagnastreymi, notendaviðmótsþættir sem notaðir eru á mismunandi undirsíðum, eru svokallaðir birgjar – bókasöfn tekin að utan, sem þarf að festa rétt við verkefni. Það er dálítið eins og heimur Lego: ef þú vilt byggja upp samhangandi heild – þá þarftu að setja hana saman úr einstökum, litlum kubbum.

Þessi allegóría vísar til nákvæmlega tengdra íhluta, sem eru kraftur forrita sem búin eru til með React eða Vue;

● Mikilvægur þáttur, sérstaklega fyrir þá sem ekki hafa mikla reynslu af JS-umhverfinu, er inngangsstigið í tiltekið bókasafn. Með öðrum orðum – flækjustig tólsins, sem felst í þeim beinu tíma sem þú þarft að verja í að skilja virkni þess.

Ég tel að eitt atriði verði að vera óskorað skýrt hér – í tilviki Vue, það er mun einfaldara. Við höfum tvíátta gagnatengingu, við höfum fágað sniðmát sem er blekkjandi líkt lausnum í öðrum forritunarmálum, t.d. Twig, og að lokum – höfum við engar höfuðverkir vegna þess að þurfa að læra kenningar um hvernig einstakir krókar virka og í hvaða tilfellum þarf að nota ákveðnar vélrænar lausnir.

Hvað segja tölfræðin?

Að fylgja beint rödd fjöldans er ekki beinlínis gott val. Hins vegar er gott skref í átt að því að taka góða ákvörðun að greina hvað þeir sem hafa átt samskipti við þessar bókasöfn segja.

Og já – Stjörnur á GitHub getur verið vísbending um hversu mikið samfélag tiltekins bókasafns tekur þátt í þróun þess, hvernig það er skynjað af forriturum og hvort þeir hafi áhuga á hvert það stefnir. Verkfræðingar Þeir sem stjörnuja ákveðinn geymslu fá oft tilkynningar um nýjar útgáfur eða kóðabreytingar, sem leiðir til þess að þeir öðlast beina þekkingu á bókasafninu.

Hins vegar ætti ekki að líta á fjölda stjarna á GitHub sem spádóm – ekki allir forritarar sem líkar við verkfæri skilja eftir sig merki – heldur myndi ég taka það sem merki um hreina ástríðu sem forritarar bera fyrir ákveðið opinn hugbúnaðarverkefni.

Google Trends er vel þekkt þjónusta sem gerir okkur kleift að rannsaka áhuga á tilteknum efnum yfir tíma. Þó að hún sé ekki rökrétt vísbending um gæði eða notkun getur hún veitt alls konar greiningar.

Auðvelt er að sjá að gangur síðustu fimm ára hefur verið nokkuð svipaður þegar kemur að samanburði á tveimur aðalpersónum greinarinnar í dag. Meginniðurstaðan sem má draga úr myndlinunni er sú að React er hærra þegar kemur að vinsældum í leit í samanburði við keppinaut sinn.

Til að vera skýr – að vera efst í Google Trends þýðir ekki að bókasafn sé betra. Þetta snýst um vinsældir meðal almennings, eins og ég nefndi áður – líklega hafa fleiri heyrt um þetta tæki, það gæti vakið meiri áhuga meðal CTOs, hugbúnaðarþróunaraðilar eða fólk sem vill bara læra á ákveðið tól.

Endurspeglast þessi mynd í raunveruleikanum? Að einhverju leyti, já. Almennt séð – meðal þeirra sem voru spurðir sýna fleiri fjölbreytta og djúpa þekkingu á React en Vue. Hvaða skoðanir geturðu fengið með því að tala við þessa einstaklinga? Ég mun reyna að draga þetta saman í næsta málsgrein.

Ástand JS  er vefsíða sem kannar árlega fólk sem vinnur við tækni tengda JavaScript. Markmið hennar er að safna upplýsingum frá forriturum um hvernig þeir líta á verkfærin sem þeir vinna með á hverjum degi.

Spurningarnar ná yfir einstök verkfæri fyrir mismunandi tilgangi – t.d. verkfæri sem notuð eru í front-end og back-end, en einnig verkfæri til prófunar, umsýslu forritarástands o.s.frv. Hverri þessara spurninga er ekki svarað með einföldu já/nei; vefsvæðið spyr röð spurninga um verkfærið sjálft, áhuga, reynslu og heildarmat sem endar í setningunni “Myndir þú nota þetta verkfæri í framtíðarverkefnum?”

Vefsíðan sjálf gerir þér kleift að framkvæma margvíslegar greiningar, bera saman viðeigandi verkfæri og stundum uppgötva síður þekktar bókasöfn sem eru að ná fótfestu í JS-heiminum, vinna sér vinsældir og njóta mikillar ánægju við notkun. Ég hvet þig eindregið til að skoða efnið á þessari síðu.

Látum okkur draga þennan kafla saman með tölfræði. Að greina mismunandi tegundir grafa getur oft verið mjög góður kostur til að bera saman ýmis atriði tengd tilteknum efnum. Hins vegar er mikilvægt að hafa í huga að að fylgja áliti meirihlutans er ekki endilega skynsamlegast. Í staðinn geturðu tekið upplýsta ákvörðun með því að nýta þér nokkra af þeim lærdómum sem draga má af greiningu á töflureiknigröfum.

Besti kosturinn fyrir forritara

Áður nefndi ég lægri inngangsmörk að Vue – í raun gerir það þér kleift að einbeita þér örlítið hraðar að raunverulegri þróun forritsins, með því að nota tólið og minnka í lágmark þann tíma sem þarf til að kynnast umhverfinu, vélfræði þess og ýmsum notkunartilvikum.

Almennt er skoðun mín sú að Vue er hentugra fyrir þá sem hafa ekki enn unnið með front-end-bókasöfnum. Vissulega gerir það þér kleift á hvetjandi hátt að ná fullnægjandi árangri á skömmum tíma.

En segjum það hávært – skortur á þekkingu á því tungumáli sem við notum til að vinna með tiltekin verkfæri mun skaða okkur fyrr eða síðar. Þetta er óverulegur þáttur í einföldum verkefnum, en eftir því sem flækjustig forritanna eykst verður sífellt erfiðara að byggja forrit á viðeigandi hátt án góðrar þekkingar á JavaScript.

Ég er ekki að vísa til þess að geta skrifað flókin fall, því þennan hluta er hægt að skipta út að mestu leyti fyrir, t.d., birgja. Ég vísa til nokkurra algengra villa sem hægt er að gera í forritunarmálinu og þess að ekki er haft vitneskju um að ranga hegðun stafi ekki af notkun bókasafnsins heldur af notkun forritunarmálsins. Algengasta villa sem birtist hér er sú svokallaða óumbreytanleiki – þ.e. þekking á vísunarmekanískunni í JavaScript.

Ég get ekki mælt með því hvaða bókasafn sé betra fyrir forritara sem eru meira eða minna kunnugir JavaScript. En ég veit eitt – ef þú vilt fá raunverulega hugmynd um hvernig þróun með báðum verkfærunum lítur út “frá innanhúss sjónarhorni” – reyndu að skrifa forrit í hvoru þeirra. Þetta gefur þér hugmynd og gerir þér kleift að sjá hvaða ferlar höfða mest til þín og hvaða valkostur hentar þér betur.

Eins og ég nefndi áður – báðar bókasöfn eru knúnar áfram af svipuðum vistkerfum og hafa svipaðar skoðanir á því að byggja forrit með litlum einingum. Báðar bókasöfnin ganga vel – engin merki eru um að hvorugt muni hverfa á næstunni. Þess vegna munu starfstilboð í báðum haldast á svipuðu stigi.

Álykendar eru einfaldar – notaðu það sem hentar þér; safnaðu reynslu og metðu hana. Þetta mun hjálpa þér að þróa rökréttan nálgun til að meta hvort betra sé að nota annan eða hinn bókasafnið í tilteknu verkefni; reyndu líka að gera tilraunir – ekkert kennir jafn djúpt og mistökin sem hafa verið gerð í fortíðinni.

Besta val fyrir CTO

Það er ekki leyndarmál að engin gullin meðal sé til sem henti sem besta lausn fyrir tiltekið verkefni. Sérstaklega í front-end-inu eldast verkfærin sem notuð eru til að byggja forrit fljótt og oft er erfitt að komast á laggirnar með nýjustu strauma.

Hins vegar ætti val á tækni ekki, eða að minnsta kosti ætti það ekki, að vera spurning um hvað fellur að núverandi straumum. Í staðinn ættum við að beina valinu að sértækum væntingum og forsendum um forritið sem við ætlum að byggja. Hvert bókasafnanna sem borin eru saman hefur sína kosti og galla, og með því að miða við notkunartilvik getum við gert sem skynsamlegasta valið.

Áhugaverður kostur gæti reynst vera tæknilýsingar stórra fyrirtækja, sem oft lýsa notkunartilfellum sínum, hvernig þróun stórra forrita hefur gengið eða gengur og hvaða mistök þau hafa gert í fortíðinni. Kannski finnum við meðal þeirra dæmi sem eru sérstaklega áhugaverð í samhengi við val á bókasafni fyrir ákveðið verkefni.

Eiginleikarnir sem við ættum að íhuga til að velja rétt verkfæri fyrir forritið sem er í smíðum eru: tími forritunarþróunar, auðveldleiki viðhald umsóknar, flækjustig forritsins og reynslu forritara af notkun tiltekinna bókasafna.

Forritarar eru þeir sem eyða mestum tíma í þau verkfæri sem ég bera saman, og þeir geta veitt bestu ráðgjöfina og hjálpað þér að taka bestu ákvörðunina í hinum mikla átökum bókasafnanna. Það er við þróun forrita sem þú sérð hin ýmsu vandamál sem spretta beint af vali á tækni, og þá hefurðu bestu yfirsýn yfir hvað gerir notkun ákveðins verkfæris fyrir ákveðna eiginleika erfiðari.

Eins og ég nefndi áður – virðast bæði bókasöfnin ekki hverfa úr markaður, að minnsta kosti ekki á næstu árum. Í stað þess að taka ákvarðanir byggðar á tölfræði og skoðunum
af ýmsum fólki af netinu – kannski er betri kostur að tala einfaldlega við forritarana.

Kynnið fyrir þeim hvað er krafist af umsókninni, hversu mikinn tíma við höfum til að skila henni og leyfið lauslega skoðanaskipti um hvað þeir hugsa um báðar lausnir áður en við tökum endanlega ákvörðun.

Ályktanir

Netastríð eru yfirleitt – eða jafnvel í öllum tilvikum – tilgangslaus. Það verða alltaf til fólk sem þrjóskulega heldur því fram að þeirra val sé betra án þess að færa nokkur rökrétt rök til stuðnings ákvörðun sinni.

Í stað þess að verða blindaður af tilteknum valkostum skulum við einbeita okkur að greiningu, reyna að draga viðeigandi ályktanir og nota þær til að aðlaga eða hafna tiltekinni lausn.

Eins og titillinn gefur til kynna ætla ég ekki að krýna neina sérstaka bókasafn sem lækningu við öllum kvillum. Í staðinn eru lagðar fram nokkrar tilgátur og styrkleikar og veikleikar beggja bókasafna varpað ljósi á. Ég hef gefið nokkur ráð um hvað beri að hafa í huga þegar valið stendur á milli þeirra, til að taka skynsamlega ákvörðun og láta ekki leiða sig af tískustraumum eða handahófskenndum einstaklingum á netinu.

Hvert tæki getur uppfyllt þarfir verkefnisins nægilega vel. Engið þeirra mun hverfa af markaðnum á næstu árum. Bæði hafa öflug samfélög og töluverða þroska, sem sýnir okkur að þau standi sig nokkuð vel.

Endanleg ákvörðun er í þínum höndum. Ef þú hefur nokkrar efasemdir eða vilt einfaldlega ræða málið þitt við The Codest – Endilega hafið samband við okkur!

Lesa meira:

Af hverju þú ættir (líklega) að nota TypeScript

Hvernig á ekki að drepa verkefni með slæmum forritunarvenjum?

Stefnur við gagnaleit í NextJS