Objektīvs skatījums uz bibliotēku karu: React pret Vue

No kurienes mēs nākam? Kas mēs esam? Kur mēs ejam?

Apstāsimies uz brīdi un apdomāsim, kur mēs atrodamies. Kā pilnīgs bumbieris es patiesi šaubos, vai pirms aptuveni 10 gadiem kāds būtu varējis paredzēt, ka... tīmekļa izstrāde varētu iet tik tālu.

Lietderīgās darbvirsmas lietojumprogrammas ir pagātne, jo visu var izdarīt pārlūkprogrammā. Patiesībā arī lietojumprogrammas, kurām jāizmanto zemāka līmeņa API, kas nav pieejami pārlūkprogrammā, tiek rakstītas, izmantojot pārlūkprogrammu dzinējus un valodas, jo tas atvieglo to uzturēšanu.

Mobilās lietojumprogrammas var viegli aizstāt ar rīkiem, ko izmanto, lai tīmekļa vietne attīstību - sk. React Vietējais, NativeScript. Turklāt mums ir PWA, kas viegli “imitē” mobilo lietojumprogrammu darbību. Turklāt komponenti, kas darbina lietojumprogrammu, kas uzrakstīta valodā Vue vai React var viegli kopīgot dažādus kods elementus starp platformām.

Mums jāatzīst viena lieta - tīmekļa lietojumprogrammas pašlaik ir spēcīgs spēks, kuru būs grūti nolaist uz zemes. Kā lietotājs es redzu, ka izmantoju tās praktiski visur: sazinoties, izmantojot Slack, lietojot koda redaktoru, veidojot prezentācijas vai pat rakstot bloga rakstu.

Ir grūti paredzēt, kas notiks pēc dažiem gadiem. WebAssembly kļūst aktuāls, un tas ļaus mums pārvietot pārlūkprogrammas, kurās nepieciešami sarežģītāki aprēķini, uz pārlūkprogrammu pasauli. Tomēr viens fakts paliek nemainīgs - ir patiešām grūti atrast šķērsli, lai, izmantojot tīmekļa tehnoloģijas, izveidotu tādu lietojumprogrammu, par kādu mēs varam tikai sapņot.

Lielais sprādziens interneta realitātē

Pie lietas būtības - atgriezīsimies uz brīdi pagātnē, pirms parādījās pirmie nozīmīgākie tīmekļa ietvari un lietojumprogrammas tika izstrādātas imperatīvā veidā. Katra interaktīvā mehānika lapā tika apstrādāta manuāli, un tā bija atbildīga par konkrētu darbību.

Labākais piemērs, ko var minēt, ir jQuery bibliotēka - savulaik viens no populārākajiem vienkāršu notikumu apstrādes risinājumiem. Ar tās palīdzību tika ieviestas dažādas nolaižamās izvēlnes, pārejas, animācijas, kalkulatori un līdzīga mehānika.

Ir vērts pieminēt, ka problēmas sarežģītākās lietojumprogrammās tika pamanītas jau tad - vietās, kur dažādām, neatkarīgām daļām bija, piemēram, react līdz pareizam klikšķim vai kaut kā rakstīšanai. Lielākajā daļā lietojumprogrammu nebija skaidra stāvokļa, tā vietā glāba, piemēram, elementu atribūti vai to klases.

Tolaik bija skaidrs, ka pašreizējai pieejai trūka reactivity - strukturēta veida, kā komponentēm savstarpēji sazināties un kopīgot, piemēram, savu stāvokli vai dažādus notikumus, kas atvieglotu lietojumprogrammu uzturēšanu un ļautu tām nodrošināt labu lietošanas pieredzi par zemām izmaksām.

Pirmie soļi ceļā uz labi zināmām sistēmām

Laika gaitā sāka parādīties pirmie front-end ietvari, kuru mērķis bija strukturēt arhitektūru sarežģītākām lietojumprogrammām.

Šie karkasi galvenokārt balstījās uz MVC modeli - daži no tiem, piemēram, Backbone.js, piedāvāja vairāk manuālu pieeju, bet citi, piemēram, Knockout.js, izmantoja divvirzienu pieeju. dati saistošs.

Tomēr varēja just, ka lietojumprogrammas rakstīšana bija sarežģītāka, prasīja daudz vairāk kodēšanas un ne vienmēr deva iecerētos rezultātus vai kompensēja lietojumprogrammas izstrādē zaudēto laiku.

Galvenais iemesls, kāpēc zelta vidusmēra atrašana JS Ekosistēma bija grūti bija tas, ka tas bija mazliet dīvainība starp labi pazīstamu programmēšanas valodas kas jau sen ir bruģējuši savu ceļu.

Un es nevēlos šeit kavēties pie tā, kādi tieši ceļi pavadīja dažādu ietvaru attīstību vēstures gaitā. Tomēr ir svarīgi atzīmēt vienu lietu - JS ekosistēmas brieduma laiks pārlūkprogrammās nebija viegls un saskārās ar daudziem pārbaudījumiem.

Tas ir vienīgais iemesls, kāpēc šodien mēs varam veidot tīmekļa lietojumprogrammas un izstrādāt tās ļoti vienkāršā un nesāpīgā veidā.

Pamatinformācija un neliels salīdzinājums

Tā vietā, lai mētātos gaļu, kā tas ir ierasts internetā, apskatīsim abas bibliotēkas, apkoposim par tām informāciju un salīdzināsim tās - gan teorētiski, gan praktiski.

PIEZĪME: mehānismu, kas darbojas Vue attiecas tieši uz 2. versiju. 3. versijā ir ieviestas daudzas būtiskas izmaiņas, taču tā nav reāls konkurents 3. versijai. React šobrīd, ja tikai tā brieduma dēļ - Vue 3 izlaišanas datums: 2020. gada 18. septembris.

Izskaidrosim vienu lietu - iedziļinoties abās bibliotēkās, var redzēt, ka patiesībā ir vairāk līdzību nekā atšķirību. Neņemot vērā bibliotēku lietošanas veidu kā tādu - abām bibliotēkām ir ļoti līdzīgas koncepcijas par to, kā tās darbojas. Abas nodrošina līdzīga ekosistēma, un to izmantošana nav diametrāli atšķirīga.

● Velns slēpjas detaļās - jo biežāk mēs izmantojam kādu rīku, jo lielākus trūkumus mēs pamanām tā dažādo risinājumu dēļ. Labs piemērs šeit var būt divvirzienu datu sasaiste, ko visbiežāk izmanto Vue kā v-modeļa īpašību: tas bieži vien atvieglo darbu, par daudzām lietām rūpējas automātiski un neprasa kodēt papildu atbalstu vērtību maiņai.

Tomēr ir gadījumi, kad mums ir īpaši jāseko līdzi izmaiņu mēģinājumam un attiecīgi react, un tādā gadījumā uz v-modeli balstītie komponenti bieži vien liek mums ķerties pie citiem. Vue mehānika, piemēram, aprēķinātā īpašība, tāpēc sasniegtais efekts bieži vien izskatās daudz sliktāks nekā ar manuālu pieeju;

● Vēl viens interesants aspekts ir JSX, kas ir šāds “vagrant” veids, kā atveidot saturu, izmantojot React. Izstrādātāju kopienā par to ir dažādi viedokļi.

Pēc maniem novērojumiem šķiet, ka izstrādātāji, kas izmanto citu vidi, nevis JS, piem. PHP vai C#, ir vairāk tendētas uz šabloniem, kas Vue dara.

Apkopojot - veidnes, kas zināmas no Vue ļauj ļoti skaidri un eleganti definēt skatus, savukārt React JSX ļauj tos veidot daudzos gadījumos ātrāk, pielāgot konkrētām vajadzībām un bieži vien prasa mazāk koda, lai izveidotu dažādas struktūras;

● Apskatīsim arī šo divu rīku ekosistēmas. Principā varam teikt, ka tās ne ar ko neatšķiras. Abus tos ne velti sauc par bibliotēkām - tie nodrošina minimumu reactīvs tīmekļa lietojumprogrammu atbalsts.

Savukārt pārējie, kas saistīti ar saziņu ar API, datu plūsma, UI komponenti, kas tiek izmantoti ap dažādām apakšlapām, ir tā sauktie pārdevēji - bibliotēkas, kas ņemtas no ārpuses un kas ir pareizi jāpievieno. projekts. Tas ir līdzīgi kā Lego pasaulē: ja vēlaties uzbūvēt vienotu veselumu, jums tas ir jāsaliek kopā no atsevišķiem, maziem klucīšiem.

Šī alegorija attiecas uz precīzi pievienotām sastāvdaļām, kas ir lietojumprogrammu, kuras izveidotas ar React vai Vue;

● Svarīgs aspekts, īpaši cilvēkiem, kuriem nav lielas pieredzes JS vidē, ir piekļuves līmenis konkrētai bibliotēkai. Citiem vārdiem sakot - rīka sarežģītība, ko veido tiešais laiks, kas jāpatērē, lai izprastu tā mehāniku.

Es domāju, ka šeit ir nepārprotami jānorāda viena lieta - attiecībā uz Vue, tas ir daudz vienkāršāk. Mums ir divvirzienu datu sasaiste, mums ir eleganti noteikts šablons, kas ir maldinoši līdzīgs citu valodu, piemēram, twig, risinājumiem, un visbeidzot - mums nav galvassāpju, ko rada teorijas apguve par atsevišķu āķu darbību un gadījumiem, kad jāizmanto konkrēta mehānika.

Ko liecina statistika?

Tieša sekošana pūļa balsij nav īsti laba izvēle. Tomēr labs solis, lai pieņemtu labu lēmumu, ir izanalizēt, ko saka cilvēki, kuri ir sadarbojušies ar šīm bibliotēkām.

Un jā - zvaigznes par github var būt rādītājs tam, cik lielā mērā konkrētās bibliotēkas kopiena ir iesaistīta tās attīstībā, kā to uztver izstrādātāji un vai viņi ir ieinteresēti, kurp tā virzās. Inženieri kuri izmanto konkrētu repozitoriju, bieži saņem paziņojumus par jaunām versijām vai izmaiņām kodā, tādējādi tiešā veidā iegūstot zināšanas par bibliotēku.

Tomēr zvaigznīšu skaitu github vietnē nevajadzētu uzskatīt par zīmi - ne katrs izstrādātājs, kuram patīk kāds rīks, atstās zīmi - tā vietā es to uzskatītu par tīras aizraušanās pazīmi, ko izstrādātāji izrāda attiecībā uz konkrētu atvērtā koda projektu.

Google Trends ir labi zināms pakalpojums, kas ļauj pētīt interesi par konkrētām tēmām laika gaitā. Lai gan tas nav racionāls kvalitātes vai izmantošanas rādītājs, tas var sniegt dažāda veida analīzi.

Salīdzinot abus šodienas raksta varoņus, ir viegli pamanīt, ka pēdējo piecu gadu gaita ir iezīmējusies diezgan līdzīgi. No diagrammas var secināt, ka galvenie secinājumi ir šādi. React meklēšanas popularitāte ir augstāka salīdzinājumā ar pretinieku.

Lai būtu skaidrs - atrašanās Google tendenču topā nenozīmē, ka bibliotēka ir labāka. Tas ir saistīts ar pūļa popularitāti, kā jau minēju iepriekš - iespējams, par šo rīku ir dzirdējuši vairāk cilvēku, tas ir izraisījis lielāku interesi starp CTOs, programmatūras izstrādātāji vai cilvēkiem, kuri vienkārši vēlas apgūt kādu konkrētu rīku.

Vai šis grafiks atspoguļojas realitātē? Nedaudz, jā. Kopumā - aptaujāto cilvēku vidū vairāk ir tādu, kas uzrāda daudzveidīgas un sarežģītas zināšanas par React nekā Vue. Kādus viedokļus jūs varat iegūt, runājot ar šiem cilvēkiem? Es centīšos to izklāstīt nākamajā rindkopā.

JS stāvoklis  ir vietne, kurā katru gadu tiek veikta ar JavaScript saistītajās tehnoloģijās strādājošo aptauja. Tās mērķis ir apkopot informāciju no izstrādātājiem par to, kā viņi vērtē rīkus, ar kuriem viņi strādā ikdienā.

Jautājumos aplūkoti atsevišķi rīki dažādiem mērķiem, piemēram, rīki, ko izmanto front-end un back-end, kā arī rīki testēšanai, lietojumprogrammas stāvokļa pārvaldībai u. c. Uz katru no šiem jautājumiem nav vienkāršas atbildes “jā/nē”, vietnē tiek uzdota virkne jautājumu par pašu rīku, interesēm, pieredzi un vispārēju novērtējumu, kas reducējas līdz teikumam "Vai jūs izmantotu šo rīku turpmākajos projektos?".”

Pati vietne ļauj veikt daudz analīžu, salīdzināt attiecīgos rīkus un dažkārt uzzināt par mazāk zināmām bibliotēkām, kas JS pasaulē sāk labi attīstīties, gūstot popularitāti un vienlaikus baudot augstu “lietošanas prieka” rādītāju. Sirsnīgi iesaku jums pārlūkot šīs vietnes saturu.

Apkoposim šo sadaļu ar statistikas datiem. Dažādu veidu grafiku analīze bieži vien var būt ļoti laba iespēja, lai salīdzinātu dažādus konkrētas tēmas aspektus. Tomēr ir svarīgi ņemt vērā, ka sekot pūļa balsij ne vienmēr būs visgudrākā rīcība. Tā vietā jūs varat pieņemt pamatotu lēmumu, izmantojot dažas no diagrammu analīzē gūtajām atziņām.

Labākā izvēle izstrādātājam

Iepriekš es minēju zemāko ieejas slieksni uz Vue - Patiesībā tas ļauj jums nedaudz ātrāk pievērsties faktiskajai lietojumprogrammas izstrādei, izmantojot rīku un līdz minimumam samazinot laiku, kas nepieciešams, lai iepazītos ar vidi, mehāniku un dažādiem lietošanas gadījumiem.

Kopumā mans viedoklis ir, ka Vue ir vairāk piemērots cilvēkiem, kuri vēl nav strādājuši ar front-end bibliotēkām. Protams, tas ļaus jums daudz iedrošinošākā veidā īsā laikā iegūt apmierinošus rezultātus.

Tomēr teiksim skaļi - valodas, kurā lietojam konkrētus rīkus, nezināšana agri vai vēlu mums kaitēs. Vienkāršām lietām tas ir nenozīmīgs elements, bet, pieaugot radīto lietojumprogrammu sarežģītībai, būs arvien grūtāk un grūtāk izveidot lietojumprogrammas pienācīgā veidā bez labām zināšanām. JavaScript.

Es īsti nerunāju par spēju rakstīt sarežģītas funkcijas, jo šo daļu lielā mērā var aizstāt, piemēram, ar pārdevējiem. Es runāju par dažām bieži sastopamām kļūdām, ko var pieļaut valodā, un neapzināšanos, ka nepareiza uzvedība nav saistīta ar bibliotēkas, bet gan ar valodas lietošanu. Visbiežāk sastopamā kļūda, kas šeit izpaužas, ir tā sauktā nemainība - tas ir, zināšanas par atsauces mehānismu JavaScript.

Es nevaru ieteikt, kura bibliotēka ir labāka izstrādātājiem, kas vairāk vai mazāk pārzina JavaScript. Bet es zinu vienu - ja vēlaties gūt reālu priekšstatu par to, kā izskatās izstrāde ar abiem rīkiem “no iekšpuses”, - pamēģiniet rakstīt lietojumprogrammas katrā no tiem. Tas sniegs jums priekšstatu, ļaus saprast, kuri mehānismi jūs uzrunā vairāk un kas jums ir labāka izvēle.

Kā jau iepriekš minēju - abas bibliotēkas darbojas līdzīgās ekosistēmās, un tām ir līdzīgi uzskati par lietojumprogrammu veidošanu ar mazām komponentēm. Abām bibliotēkām klājas labi - nekas neliecina, ka kāda no tām tuvākajā nākotnē izzudīs. Līdz ar to darba piedāvājumi abās saglabāsies līdzīgā līmenī.

Secinājumi ir vienkārši - izmantojiet to, kas jums ir piemērots, uzkrājiet pieredzi un izvērtējiet. Tas palīdzēs jums izstrādāt racionālu pieeju tam, vai konkrētajā projektā labāk izmantot vienu vai otru bibliotēku; turklāt mēģiniet eksperimentēt - nekas nemāca tik dziļi kā pagātnē pieļautās kļūdas.

Labākais izvēle CTO

Nav noslēpums, ka nav zelta vidusceļa, kas būtu labākais risinājums konkrētam projektam. Jo īpaši front-end lietojumprogrammu izveidē izmantotie rīki ātri noveco, un bieži vien ir grūti orientēties jaunākajās tendencēs.

Tomēr tehnoloģiju izvēle nav vai vismaz nevajadzētu būt atkarīga no tā, kas atbilst pašreizējām tendencēm. Tā vietā mums tā būtu jāvirza uz konkrētām gaidām un pieņēmumiem par lietojumprogrammu, ko gatavojamies izveidot. Katrai no salīdzinātajām bibliotēkām ir savas stiprās un vājās puses, kas, saskaņotas ar lietošanas gadījumu, ļaus mums izdarīt vispamatotāko izvēli.

Interesants variants var izrādīties lielo korporāciju tehnoloģiju kopsavilkumi, kuros bieži aprakstīti to lietojuma gadījumi, kā noritēja vai norit milzīgu lietojumprogrammu izstrāde un kādas kļūdas tās pieļāvušas pagātnē. Iespējams, starp tiem atradīsim gadījumus, kas ir īpaši interesanti kontekstā ar bibliotēkas izvēli konkrētam projektam.

Iezīmes, kas jāņem vērā, lai izvēlētos pareizos rīkus veidojamai lietojumprogrammai, ir šādas: lietojumprogrammas izstrādes laiks, lietošanas ērtums, lietojumprogrammas izstrādes ilgums, lietojumprogrammas izstrādes vieglums, lietojumprogrammas lietojumprogrammas uzturēšana, lietojumprogrammas sarežģītību un izstrādātāju pieredzi konkrētu bibliotēku izmantošanā.

Izstrādātāji ir cilvēki, kuri visvairāk laika pavada ar manis salīdzinātajiem rīkiem, un viņi ir tie, kuri var sniegt labākos padomus un palīdzēt jums izdarīt labāko izvēli lielajā bibliotēku sadursmē. Tieši lietojumprogrammu izstrādes laikā jūs redzat dažādas problēmas, kas rodas tieši no tehnoloģijas izvēles, un vislabāk redzat, kādas lietas apgrūtina konkrēta rīka izmantošanu konkrētām funkcijām.

Kā jau minēju iepriekš - abas bibliotēkas, šķiet, nepazūd no tirgus, vismaz ne tuvākajos gados. Tā vietā, lai pieņemtu lēmumus, pamatojoties uz statistiku un viedokļiem
no dažādiem cilvēkiem internetā - varbūt labāks risinājums ir vienkārši aprunāties ar izstrādātājiem.

Iepazīstiniet viņus ar to, ko sagaidām no pieteikuma, kāds laiks ir atvēlēts tā iesniegšanai, un ļaujiet viņiem brīvi apmainīties viedokļiem par to, ko viņi domā par abiem risinājumiem, pirms mēs pieņemam galīgo lēmumu.

Secinājumi

Interneta kari parasti - vai varbūt visos gadījumos - ir bezjēdzīgi. Vienmēr atradīsies cilvēki, kas spītīgi apgalvos, ka viņu izvēle ir labāka, nesniedzot nekādus racionālus argumentus, kas apstiprinātu viņu lēmumu.

Tā vietā, lai apžilbinātu ar konkrētām izvēlēm, koncentrēsimies uz analīzi, mēģināsim izdarīt atbilstošus secinājumus un izmantot tos, lai pielāgotu vai noraidītu konkrētu risinājumu.

Kā jau norāda virsraksts - es negribu vainagot kādu konkrētu bibliotēku kā līdzekli pret visām sāpēm. Tā vietā tiek izvirzītas dažas hipotēzes un atklātas abu bibliotēku stiprās un vājās puses. Esmu sniedzis dažus padomus par to, kam pievērst uzmanību, izvēloties starp tām, lai pieņemtu gudru lēmumu un nevadītos pēc tendencēm vai nejaušiem cilvēkiem no interneta.

Katrs rīks var pietiekami labi atbilst projekta vajadzībām. Neviens no tiem tuvākajos gados ātri nepazudīs no tirgus. Abiem ir spēcīgas kopienas un diezgan liela brieduma pakāpe, kas liecina, ka šiem diviem rīkiem klājas diezgan labi.

Galīgā izvēle ir jūsu rokās. Tomēr, ja jums ir kādas šaubas vai vienkārši vēlaties apspriest savu lietu ar The Codest - sazinieties ar mums!

Lasīt vairāk:

Kāpēc jums (iespējams) vajadzētu izmantot Typescript

Kā nenogalināt projektu ar sliktu kodēšanas praksi?

Datu iegūšanas stratēģijas NextJS