Objektiivne pilk raamatukogusõjale: React vs Vue

Kust me tuleme? Mis me oleme? Kuhu me läheme?

Peatume hetkeks ja mõtleme, kus me oleme. Täieliku bumeranikuna kahtlen siiralt, et umbes 10 aastat tagasi oleks keegi osanud ennustada, et veebiarendus läheks nii kaugele.

Töölauarakendused kuuluvad minevikku, sest kõike saab teha veebilehitsejas. Tegelikult kirjutatakse ka rakendusi, mis peavad kasutama madalama taseme APIsid, mis ei ole brauseris kättesaadavad, kasutades brauserimootoreid ja -keeli, sest see muudab nende hooldamise lihtsamaks.

Mobiilirakendusi saab hõlpsasti asendada veebiarenduseks kasutatavate vahenditega - vt. React Native, NativeScript. Lisaks on meil PWA, mis kergesti "imiteerib" mobiilirakenduste toimimist. Lisaks on komponendid, mis toidavad rakendust, mis on kirjutatud Vue või React saab hõlpsasti jagada erinevaid kood elemente platvormide vahel.

Peame tunnistama üht - veebirakendused on praegu võimsad, mida on raske alla tuua. Kasutajana näen end neid praktiliselt kõikjal kasutamas: Slacki kaudu suhtlemisel, koodiredaktori kasutamisel, esitluste tegemisel või isegi blogiartikli kirjutamisel.

Raske on ennustada, mis juhtub mõne aasta pärast. WebAssembly tuleb mängu ja see võimaldab meil keerulisemaid arvutusi nõudvad rakendused brauserimaailma üle viia. Üks fakt jääb aga muutumatuks - tõesti on raske leida takistust ehitada veebitehnoloogiate abil sellist rakendust, millest me ainult unistada oskame.

Suur pauk internetireaalsuses

Asja juurde - läheme korraks tagasi minevikku, enne esimeste olulisemate veebiraamistike ilmumist ja rakenduste imperatiivset arendamist. Iga interaktiivset mehhanismi lehel käsitleti käsitsi ja see oli vastutav konkreetse tegevuse eest.

Parim näide, mida võib tuua, on jQuery raamatukogu - omal ajal üks populaarsemaid lahendusi lihtsate sündmuste käsitlemiseks. Selle abil on rakendatud erinevaid rippmenüüsid, üleminekuid, animatsioone, kalkulaatoreid ja muud sarnast mehaanikat.

Tasub mainida, et probleeme keerulisemates rakendustes märgati juba siis - kohtades, kus erinevad, iseseisvad osad pidid näiteks reageerima korralikule klõpsule või millegi sisestamisele. Enamikul rakendustest ei olnud selgesõnalist olekut, vaid neid päästsid näiteks elementide atribuudid või nende klassid.

Sel ajal oli selge, et praegusel lähenemisviisil puudus reaktiivsus - struktureeritud viis, kuidas komponendid omavahel suhelda ja jagada näiteks oma olekut või erinevaid sündmusi, mis lihtsustas rakenduste hooldamist ja võimaldas neil pakkuda head kasutajakogemust väikeste kuludega.

Esimesed sammud tuntud raamistike suunas

Aja jooksul hakkasid ilmuma esimesed front-end raamistikud, mille eesmärk oli struktureerida arhitektuuri keerukamate rakenduste jaoks.

Need raamistikud põhinesid peamiselt MVC-mustril - mõned pakkusid välja rohkem manuaalset lähenemist, nagu Backbone.js, samas kui teised, nagu Knockout.js, haakusid kahesuunalise andmesidumisega.

Siiski võis tunda, et rakenduse kirjutamine oli keerulisem, nõudis palju rohkem kodeerimist ja ei andnud tingimata soovitud tulemusi ega kompenseerinud rakenduse arendamisele kaotatud aega.

Peamine põhjus, miks kuldse kesktee leidmine JS-ökosüsteemis oli raske, oli see, et see oli tuntud programmeerimiskeeled mis on juba ammu oma teed sillutanud.

Ja ma ei taha siinkohal pikemalt peatuda sellel, millised teed on erinevate raamistike arenguga läbi ajaloo kaasnenud. Siiski on oluline märkida üht - JS-ökosüsteemi küpsemise aeg brauserites ei olnud lihtne ja seisis silmitsi paljude katsumustega.

See on ainus põhjus, miks me saame tänapäeval ehitada veebirakendusi ja arendada neid väga lihtsalt ja valutult.

Põhiteave ja väike võrdlus

Selle asemel, et visata liha, nagu internetis kombeks, vaatame mõlemad raamatukogud üle, kogume nende kohta infot ja võrdleme neid - nii teoorias kui ka praktikas.

MÄRKUS: mehhanismide kirjeldus, mis töötavad Vue viitab konkreetselt versioonile 2. Versioon 3 toob palju olulisi muudatusi, kuid ei ole tõeline konkurent React hetkel, kui ainult oma küpsuse tõttu - Vue 3 ilmumiskuupäev: 18. september 2020.

Tehkem üks asi selgeks - kui süveneda mõlemasse raamatukogusse, siis näete, et tegelikult on sarnasusi rohkem kui erinevusi. Jättes kõrvale raamatukogude kasutamise viisi kui sellise - mõlemal neist on väga sarnased kontseptsioonid, kuidas nad töötavad. Mõlemad põhinevad sarnasel ökosüsteemil ja nende kasutamine ei ole diametraalselt erinev.

● Kurat peitub detailides - mida sagedamini me mingit vahendit kasutame, seda suuremaid puudusi selle erinevatest lahendustest märkame. Heaks näiteks võib siinkohal olla kahesuunaline andmete sidumine, mida kasutatakse kõige sagedamini Vue kui v-mudeli omadus: see muudab sageli asjad lihtsamaks, hoolitseb paljude asjade eest automaatselt ja ei nõua väärtuste muutmise lisatoe kodeerimist.

Siiski on juhtumeid, kus meil on vaja konkreetselt jälgida muutmiskatset ja sellele vastavalt reageerida, mille puhul v-mudelil põhinevate komponentide puhul oleme sageli sunnitud segama teiste Vue mehaanika, nagu näiteks arvutatud vara, mistõttu saavutatud efekt näeb sageli palju halvem välja kui manuaalse lähenemise puhul;

● Teine huvitav aspekt on JSX, mis on selline "vagrantne" viis renderdatud sisu mallimiseks, kasutades React. Arendajaskonnas on erinevad arvamused.

Minu tähelepanekute põhjal tundub, et arendajad, kes kasutavad muud keskkonda kui JS, nt. PHP või C#, kalduvad rohkem mallivaateid nii, et Vue teeb.

Kokkuvõtteks - mallid, mis on tuntud alates Vue võimaldavad määratleda vaateid väga selgelt ja elegantselt, samas kui React JSX võimaldab neid paljudel juhtudel kiiremini ehitada, kohandada neid konkreetsetele vajadustele ja nõuab sageli vähem koodi erinevate struktuuride loomiseks;

● Vaadakem ka nende kahe vahendi ökosüsteeme. Põhimõtteliselt võime öelda, et nad ei erine millegi poolest. Mõlemaid nimetatakse raamatukogudeks mitte ilma põhjuseta - nad pakuvad reaktiivsete veebirakenduste toetuseks minimaalset vajalikku.

Samas kui ülejäänud, mis on seotud API-ga suhtlemise, andmevoo, erinevate alamlehtede ümber kasutatavate UI-komponentidega, on nn müüjad - väljastpoolt võetud raamatukogud, mis tuleb korralikult kinnitada projekt. See on natuke nagu Lego maailm: kui tahad ehitada ühtset tervikut, pead selle kokku panema üksikutest väikestest klotsidest.

See allegooria viitab täpselt lisatud komponentidele, mis on võimsad rakendused, mis on loodud koos React või Vue;

● Oluline asi, eriti inimeste jaoks, kes ei ole JS-keskkonnas nii kogenud, on konkreetse raamatukogu sisenemise tase. Teisisõnu - tööriista keerukus, mis koosneb otsesest ajast, mida peate kulutama selle mehaanika mõistmiseks.

Ma arvan, et üks asi tuleb siinkohal ühemõtteliselt välja öelda - juhul kui tegemist on Vuesee on palju lihtsam. Meil on kahesuunaline andmete sidumine, meil on elegantselt määratletud mall, mis on petlikult sarnane teiste keelte lahendustega, nt twig, ja lõpuks - meil ei ole peavalu, mida põhjustab üksikute konksude toimimist puudutavate teooriate õppimine ja juhtumid, mille puhul tuleb kasutada spetsiifilist mehaanikat.

Mida ütleb statistika?

Otse rahvahääle järgi minek ei ole just hea valik. Hea samm hea otsuse tegemiseks on siiski analüüsida, mida ütlevad inimesed, kes on nende raamatukogudega suhelnud.

Ja jah - tähed githubis võib olla näitaja selle kohta, kui palju on konkreetse raamatukogu kogukond selle arendamisse kaasatud, kuidas arendajad seda tajuvad ja kas nad on huvitatud sellest, kuhu raamatukogu areneb. Konkreetset repositooriumi staarid saavad sageli teateid uute versioonide või koodimuudatuste kohta, mis tähendab, et nad teavad otseselt, mis raamatukogus toimub.

Siiski ei tohiks githubi tärnide arvu pidada oraakliks - mitte iga arendaja, kellele tööriist meeldib, ei jäta märki - selle asemel võtaksin seda kui märki puhtast kirest, mida arendajad konkreetse avatud lähtekoodiga projekti vastu tunnevad.

Google Trends on tuntud teenus, mis võimaldab uurida huvi konkreetsete teemade vastu aja jooksul. Kuigi see ei ole ratsionaalne kvaliteedi või kasutamise näitaja, võib see pakkuda igasuguseid analüüse.

Tänase artikli kahe peategelase võrdlemisel on lihtne näha, et viimase 5 aasta kulg on olnud üsna sarnane. Põhiline järeldus, mille võib graafiku põhjal teha, on, et React on otsingupopulaarsuse poolest kõrgem võrreldes oma konkurendiga.

Selgituseks - Google Trends'i edetabelis esikohal olemine ei tähenda, et raamatukogu on parem. Küsimus on rahvahulga populaarsuses, nagu ma juba mainisin - tõenäoliselt on rohkem inimesi sellest tööriistast kuulnud, see võib olla äratanud rohkem huvi seas CTOs, tarkvaraarendajad või inimesed, kes soovivad lihtsalt õppida mingit konkreetset tööriista.

Kas see graafik kajastab tegelikkust? Mõnevõrra, jah. Üldiselt - küsitletud inimeste seas on rohkem neid, kes näitavad mitmekesiselt keerulisi teadmisi React kui Vue. Milliseid arvamusi saab nende inimestega rääkides? Püüan seda järgmises lõigus visandada.

JS riik  on sait, mis uurib igal aastal inimesi, kes töötavad JavaScript-ga seotud tehnoloogiate valdkonnas. Selle eesmärk on koguda arendajatelt teavet selle kohta, kuidas nad suhtuvad tööriistadesse, millega nad igapäevaselt töötavad.

Küsimused hõlmavad üksikuid vahendeid eri eesmärkidel - nt vahendeid, mida kasutatakse front-end'is ja back-end'is, aga ka vahendeid testimiseks, rakenduse seisundi haldamiseks jne. Igale küsimusele ei saa vastata lihtsalt jah/ei, vaid saidil esitatakse rida küsimusi tööriista enda, huvide, kogemuste ja üldise hinnangu kohta, mis taandub lausele "Kas te kasutaksite seda tööriista tulevastes projektides?".

Sait ise võimaldab teil teha palju analüüse, võrrelda asjakohaseid vahendeid ja mõnikord teada saada vähemtuntud raamatukogudest, mis hakkavad JS-maailmas hästi hakkama saama, kogudes populaarsust, nautides samal ajal kõrget "kasutamise rõõmu" määra. Soovitan siiralt sirvida selle saidi sisu.

Võtame lõigu kokku statistika abil. Erinevat tüüpi graafikute analüüs võib sageli olla väga hea võimalus antud teemade erinevate aspektide võrdlemiseks. Siiski tuleb arvestada, et rahvahulga hääle järgimine ei pruugi olla kõige targem. Selle asemel saate teha teadliku otsuse, kasutades mõningaid graafikute analüüsist saadud õppetunde.

Parim valik arendaja jaoks

Varem mainisin madalamat sisenemislävendit, et Vue - see võimaldab tõepoolest keskenduda veidi kiiremini rakenduse tegelikule arendamisele, kasutades tööriista ja vähendades miinimumini aega, mis on vajalik keskkonna, mehaanika ja erinevate kasutusjuhtumitega tutvumiseks.

Üldiselt on minu arvamus, et Vue on sobivam inimestele, kes ei ole veel tegelenud front-end raamatukogudega. Kindlasti võimaldab see teil julgemalt saada rahuldavaid tulemusi lühikese aja jooksul.

Kuid ütleme seda valjusti - keeleoskuse puudumine, milles me kasutame konkreetseid vahendeid, teeb meile varem või hiljem haiget. Lihtsate asjade puhul on see tähtsusetu element, kuid kui loodavate rakenduste keerukus kasvab, siis on üha raskem ehitada rakendusi korralikult ilma hea teadmisteta JavaScript.

Ma ei viita tegelikult sellele, et ma suudan kirjutada mingeid keerulisi funktsioone, sest seda osa saab suures osas asendada näiteks müüjate poolt. Ma pean silmas mõningaid tavalisi vigu, mida võib keeles teha ja mitte teadvustada, et vale käitumine ei tulene mitte raamatukogu, vaid keele kasutamisest. Kõige tavalisem viga, mis siin avaldub, on nn muutumatus - see tähendab, et JavaScript-s on teada viitamismehhanism.

Ma ei oska soovitada, milline raamatukogu on parem arendajatele, kes on rohkem või vähem tuttavad JavaScript-ga. Aga ma tean ühte asja - kui soovite saada tõelist ettekujutust sellest, kuidas areng mõlema tööriistaga "seestpoolt" välja näeb - proovige kirjutada rakendusi mõlemas neist. See annab teile ettekujutuse, võimaldab teil näha, millised mehhanismid teile rohkem meeldivad ja mis on teie jaoks parem valik.

Nagu ma varem mainisin - mõlemad raamatukogud põhinevad sarnastel ökosüsteemidel, neil on sarnased vaated rakenduste loomisele väikeste komponentidega. Mõlemal raamatukogul läheb hästi - ei ole mingeid märke, et kumbki neist lähitulevikus kaduma hakkab. Järelikult jäävad ka tööpakkumised mõlemas sarnasel tasemel.

Järeldused on lihtsad - kasutage seda, mis teile sobib; koguge kogemusi ja hinnake. See aitab teil arendada ratsionaalset lähenemist sellele, kas konkreetses projektis on parem kasutada üht või teist raamatukogu; proovige ka katsetada - miski ei õpeta nii põhjalikult kui minevikus tehtud vead.

Parim valik CTO jaoks

Ei ole saladus, et ei ole olemas kuldset keskmist, mis oleks konkreetse projekti jaoks parim lahendus. Eriti front-endis vananevad rakenduste ehitamiseks kasutatavad tööriistad kiiresti ja tihti on raske leida jalga uusimatele suundumustele.

Kuid tehnoloogia valik ei ole või vähemalt ei tohiks olla sõltuvuses sellest, mis sobib praeguste suundumustega. Selle asemel peaksime selle suunama konkreetsete ootuste ja eelduste järgi, mis on seotud rakendusega, mida me ehitame. Igal võrreldud raamatukogul on oma tugevad ja nõrgad küljed, mida sobitades kasutuskohaga saame teha kõige mõistlikuma valiku.

Huvitavaks võimaluseks võivad osutuda suurettevõtete tehnoloogilised kokkuvõtted, kus sageli kirjeldatakse nende kasutusjuhtumeid, kuidas suurte rakenduste arendamine kulges või kulgeb ja milliseid vigu nad minevikus tegid. Võib-olla leiame nende hulgast juhtumeid, mis on eriti huvitavad konkreetse projekti jaoks raamatukogu valimise kontekstis.

Omadused, mida peaksime arvestama, et valida õiged tööriistad loodava rakenduse jaoks, on: rakenduse arendamise aeg, lihtsus ja rakenduse hooldus, rakenduse keerukus ja arendajate kogemus konkreetsete raamatukogude kasutamisel.

Arendajad on need inimesed, kes veedavad kõige rohkem aega tööriistadega, mida ma võrdlen, ja nad on need, kes saavad anda parimat nõu ja aidata teil teha parim valik raamatukogude suures kokkupõrkes. Just rakenduse arendamise käigus näed erinevaid probleeme, mis tulenevad otseselt tehnoloogia valikust, ja sul on parim ülevaade sellest, millised asjad õõnestavad konkreetse tööriista kasutamist konkreetsete funktsioonide puhul.

Nagu ma varem mainisin - mõlemad raamatukogud ei tundu kaduvat välja turg, vähemalt mitte lähiaastatel. Selle asemel, et teha otsuseid statistika ja arvamuste põhjal
erinevatest inimestest internetist - võib-olla on parem variant lihtsalt rääkida arendajatega.

Tutvustage neile, mida taotlustelt oodatakse, milline aeg meil selle tarnimiseks on ja lubage enne lõpliku otsuse tegemist vabalt vahetada arvamusi selle kohta, mida nad mõlemast lahendusest arvavad.

Järeldused

Interneti-sõjad on tavaliselt - või võib-olla igal juhul - mõttetud. Alati leidub inimesi, kes väidavad kangekaelselt, et nende valik on parem, ilma et nad esitaksid oma otsust kinnitavaid ratsionaalseid argumente.

Selle asemel, et olla pimestatud konkreetsetest valikutest - keskendume analüüsile, püüame teha asjakohaseid järeldusi ja kasutada neid konkreetse lahenduse kohandamiseks või tagasilükkamiseks.

Nagu pealkiri viitab - ma ei kavatse kroonida ühtegi konkreetset raamatukogu kui ravimit igale valule. Selle asemel esitatakse mõned hüpoteesid ning tuuakse välja mõlema raamatukogu tugevad ja nõrgad küljed. Olen andnud mõned nõuanded, mida nende vahel valides otsida, et teha tark otsus ja mitte juhinduda trendidest või juhuslikest inimestest internetist.

Iga tööriist võib projekti vajadustele piisavalt hästi sobida. Kumbki neist ei kao lähiaastatel kiiresti turult. Mõlemal on võimsad kogukonnad ja üsna küpsed, mis näitab meile, et neil kahel läheb päris hästi.

Lõplik valik on teie käes. Kui teil on siiski mingeid kahtlusi või soovite lihtsalt arutada oma juhtumit The Codest-ga - võtke meiega julgelt ühendust!

Loe edasi:

Miks peaksite (tõenäoliselt) kasutama Typescript'i

Kuidas mitte tappa projekti halbade kodeerimistavadega?

NextJS-i andmete hankimise strateegiad