GRĮŽTI ATGAL
Spartus interneto augimas, prasidėjęs maždaug prieš 10 metų, sukėlė didelę painiavą interneto pasaulyje. Jis ne tik suteikė galimybę daugiau dalykų atlikti naršyklėje, bet ir pakeitė bendrą požiūrį į programų kūrimą. Tačiau toks požiūris pareikalavo tam tikrų patobulinimų prižiūrint naršykle grindžiamų programų kodą. Tuo metu buvo kuriami pirmieji front-end karkasai. Du iš jų šiandien panagrinėsiu po mikroskopu.
Akimirkai sustokime ir apsvarstykime, kur esame. Kaip visiškas bumo amžius, nuoširdžiai abejoju, ar prieš maždaug 10 metų kas nors būtų galėjęs numatyti, kad žiniatinklio kūrimas nueitų taip toli.
Komunalinės darbalaukio programos jau praeityje, nes viską galima atlikti naršyklėje. Tiesą sakant, taikomosios programos, kurioms reikia naudoti žemesnio lygio API, kurių nėra naršyklėje, taip pat rašomos naudojant naršyklės variklius ir kalbas, nes jas lengviau prižiūrėti.
Mobiliąsias programas galima lengvai pakeisti įrankiais, naudojamais žiniatinklio svetainė plėtrą - žr. React Gimtoji kalba, NativeScript. Be to, turime PWA, kuris lengvai “imituoja” mobiliųjų programų veikimą. Be to, komponentai, kurie maitina programą, parašytą Vue arba React galite lengvai dalytis įvairiais kodas elementus tarp platformų.
Turime pripažinti vieną dalyką - šiuo metu žiniatinklio programos yra galingas įrenginys, kurį bus sunku nuleisti į žemesnį lygį. Kaip naudotojas matau save naudojant jas praktiškai visur: bendraujant per "Slack", naudojantis kodo redaktoriumi, rengiant pristatymus ar net rašant tinklaraščio straipsnį.
Sunku nuspėti, kas nutiks po kelerių metų. "WebAssembly" pradės veikti, ir tai leis mus perkelti sudėtingesnių skaičiavimų reikalaujančias programas į naršyklės pasaulį. Tačiau vienas faktas išlieka nepakitęs - tikrai sunku rasti kliūčių naudojant žiniatinklio technologijas sukurti tokią programą, apie kurią galime tik pasvajoti.
Grįžkime trumpam į praeitį, kol pasirodė pirmieji svarbesni žiniatinklio karkasai ir programos buvo kuriamos imperatyviai. Kiekviena interaktyvioji puslapio mechanika buvo tvarkoma rankiniu būdu ir buvo atsakinga už konkretų veiksmą.
Geriausias pavyzdys - jQuery biblioteka, kuri tuo metu buvo vienas populiariausių sprendimų paprastiems įvykiams tvarkyti. Jos pagalba buvo įgyvendinami įvairūs išskleidžiamieji meniu, perėjimai, animacijos, skaičiuotuvai ir panašios mechanikos.
Verta paminėti, kad jau tada buvo pastebėtos problemos sudėtingesnėse programose - tose vietose, kur skirtingos nepriklausomos dalys turėjo, pvz., react tinkamai spustelėti arba ką nors įvesti. Dauguma taikomųjų programų neturėjo aiškios būsenos, o jas gelbėjo, pavyzdžiui, elementų atributai arba jų klasės.
Tuo metu buvo aišku, kad dabartiniam požiūriui trūko reactivity - struktūrizuoto būdo komponentams bendrauti tarpusavyje ir dalytis, pavyzdžiui, savo būkle ar įvairiais įvykiais, todėl programas buvo lengviau prižiūrėti ir jos galėjo teikti gerą naudotojo patirtį už mažą kainą.
Laikui bėgant pradėjo rastis pirmieji front-end karkasai, kuriais buvo siekiama struktūrizuoti sudėtingesnių programų architektūrą.
Šie karkasai daugiausia buvo grindžiami MVC modeliu - vieni siūlė labiau rankinį požiūrį, pavyzdžiui, Backbone.js, o kiti, pavyzdžiui, Knockout.js, buvo prijungti prie dvipusio duomenys surišimas.
Vis dėlto galima manyti, kad parašyti programą buvo sunkiau, reikėjo kur kas daugiau kodavimo ir nebūtinai buvo pasiekta numatytų rezultatų ar kompensuotas programai kurti sugaištas laikas.
Pagrindinė priežastis, dėl kurios aukso vidurio paieška JS Ekosistema buvo sunku buvo tai, kad ji buvo šiek tiek keistumas tarp gerai žinomų programavimo kalbos kuriems jau seniai nutiesti keliai.
Nenoriu čia kalbėti apie tai, kokie tiksliai keliai lydėjo įvairių sistemų kūrimą istorijos eigoje. Tačiau svarbu atkreipti dėmesį į vieną dalyką - JS ekosistemos naršyklėse brendimo laikas nebuvo lengvas ir susidūrė su daugybe išbandymų.
Tik dėl šios priežasties šiandien galime kurti žiniatinklio programėles ir kurti jas labai lengvai ir neskausmingai.
Užuot mėtęsi mėsa, kaip įprasta internete, apžvelkime abi bibliotekas, suraskime apie jas informacijos ir palyginkime jas - tiek teoriškai, tiek praktiškai.
PASTABA: Mechanizmų, veikiančių Vue konkrečiai kalbama apie 2 versiją. 3 versijoje atlikta daug svarbių pakeitimų, tačiau ji nėra tikra konkurentė React šiuo metu, jei tik dėl savo brandos - Vue 3 išleidimo data: 2020 m. rugsėjo 18 d.
Išsiaiškinkime vieną dalyką - įsigilinę į abi bibliotekas pamatysite, kad iš tikrųjų yra daugiau panašumų nei skirtumų. Nesigilinant į bibliotekų naudojimo būdą, abiejų bibliotekų veikimo koncepcijos yra labai panašios. Abi jos veikia panašioje ekosistemoje ir jų naudojimas nėra diametraliai skirtingas.
● Velnias slypi detalėse - kuo dažniau naudojame įrankį, tuo daugiau pastebime įvairių jo sprendimų trūkumų. Geras pavyzdys gali būti dvipusis duomenų susiejimas, kuris dažniausiai naudojamas Vue kaip v-modelio savybė: tai dažnai palengvina darbą, daugelį dalykų išsprendžia automatiškai ir nereikalauja papildomos reikšmių keitimo paramos.
Tačiau pasitaiko atvejų, kai reikia konkrečiai sekti bandymą keisti ir atitinkamai react, o tokiu atveju v-modeliu pagrįsti komponentai dažnai verčia mus vargti su kitais Vue mechanikos, pavyzdžiui, apskaičiuotos savybės, todėl pasiektas efektas dažnai atrodo daug blogiau nei naudojant rankinį metodą;
● Kitas įdomus aspektas yra JSX, kuris yra toks “klajokliškas” būdas šablonizuoti atvaizduojamą turinį naudojant React. Kūrėjų bendruomenė apie jį turi įvairių nuomonių.
Mano pastebėjimais, atrodo, kad kūrėjai, naudojantys ne JS aplinką, pvz. PHP arba C#, yra labiau linkę šablonizuoti vaizdus taip, kad Vue daro.
Apibendrinant - šablonai, žinomi iš Vue leidžia labai aiškiai ir elegantiškai apibrėžti vaizdus, o React JSX daugeliu atvejų leidžia juos kurti greičiau, pritaikyti prie konkrečių poreikių ir dažnai reikia mažiau kodo įvairioms struktūroms kurti;
● Taip pat apžvelkime šių dviejų įrankių ekosistemas. Iš esmės galime teigti, kad jos niekuo nesiskiria. Abi jos ne veltui vadinamos bibliotekomis - jos užtikrina būtiniausią reactive žiniatinklio programų palaikymą.
o likusi dalis, susijusi su bendravimu su API, duomenų srautas, naudotojo sąsajos komponentai, naudojami aplink skirtingus tinklalapius, yra vadinamieji pardavėjai - iš išorės paimtos bibliotekos, kurias reikia tinkamai prijungti prie projektas. Tai šiek tiek panašu į "Lego" pasaulį: jei norite pastatyti darnią visumą, turite ją surinkti iš atskirų mažų kaladėlių.
Ši alegorija susijusi su tiksliai pritvirtintomis sudedamosiomis dalimis, kurios yra programų, sukurtų naudojant React arba Vue;
● Svarbus dalykas, ypač žmonėms, kurie neturi daug patirties JS aplinkoje, yra įėjimo į konkrečią biblioteką lygis. Kitaip tariant, įrankio sudėtingumas, kurį sudaro tiesioginis laikas, kurį reikia skirti jo mechanikos supratimui.
Manau, kad čia reikia nedviprasmiškai pasakyti vieną dalyką - dėl Vue, tai daug paprasčiau. Turime dvipusį duomenų susiejimą, elegantiškai nurodytą šabloną, kuris apgaulingai panašus į kitų kalbų, pavyzdžiui, twig, sprendimus, ir galiausiai - neturime galvos skausmo, kurį sukelia teorijos apie atskirų kabliukų veikimą ir atvejus, kai reikia naudoti konkrečią mechaniką, mokymasis.
Tiesioginis minios balsas nėra geras pasirinkimas. Tačiau geras žingsnis link gero sprendimo - išanalizuoti, ką sako su šiomis bibliotekomis bendravę žmonės.
Ir taip - žvaigždės github gali būti rodiklis, rodantis, kiek konkrečios bibliotekos bendruomenė dalyvauja jos kūrime, kaip ją suvokia kūrėjai ir ar jiems įdomu, kur link ji eina. Inžinieriai kurie naudojasi tam tikra saugykla, dažnai gauna pranešimus apie naujus leidimus ar kodo pakeitimus, o tai reiškia, kad jie tiesiogiai žino biblioteką.
Tačiau žvaigždučių skaičiaus "github" sistemoje nereikėtų vertinti kaip orakulo - ne kiekvienas programuotojas, kuriam patinka įrankis, paliks ženklą, o vertinčiau jį kaip gryną programuotojų aistros tam tikram atvirojo kodo projektui ženklą.
"Google Trends yra gerai žinoma paslauga, leidžianti tirti susidomėjimą konkrečiomis temomis per tam tikrą laiką. Nors tai nėra racionalus kokybės ar naudojimo rodiklis, ji gali padėti atlikti įvairias analizes.
Nesunku pastebėti, kad pastarųjų penkerių metų eiga buvo gana panaši, kai reikia palyginti du šiandienos straipsnio herojus. Pagrindinė išvada, kurią galima padaryti iš diagramos, yra tokia. React paieškos populiarumas yra didesnis, palyginti su jos priešininku.
Kad būtų aišku - buvimas "Google Trends" viršūnėje nereiškia, kad biblioteka yra geresnė. Tai susiję su minios populiarumu, kaip jau minėjau anksčiau - tikriausiai apie šį įrankį girdėjo daugiau žmonių, jis galėjo sukelti didesnį susidomėjimą tarp CTOs, programinės įrangos kūrėjai arba žmonės, kurie tiesiog nori išmokti tam tikrą įrankį.
Ar ši diagrama atspindi tikrovę? Iš dalies taip. Apskritai - tarp apklaustų žmonių daugiau tokių, kurie rodo įvairiapusiškai išlavintas žinias apie React nei Vue. Kokią nuomonę galite sužinoti kalbėdamiesi su šiais žmonėmis? Pabandysiu tai išdėstyti kitoje pastraipoje.
JS būklė tai svetainė, kurioje kasmet atliekamos su JavaScript susijusiomis technologijomis dirbančių žmonių apklausos. Jos tikslas - surinkti informaciją iš kūrėjų apie tai, kaip jie vertina įrankius, su kuriais dirba kasdien.
Klausimai apima atskiras įvairios paskirties priemones, pvz., front-end ir back-end, taip pat testavimo, taikomosios programos būsenos valdymo ir kt. priemones. Į kiekvieną iš šių klausimų nėra paprasto atsakymo “taip” / "ne", svetainėje užduodama nemažai klausimų apie pačią priemonę, pomėgius, patirtį ir bendrą vertinimą, kuris susiveda į sakinį "Ar naudotumėte šią priemonę būsimuose projektuose?".”
Pačioje svetainėje galima atlikti daugybę analizių, palyginti atitinkamus įrankius ir kartais sužinoti apie mažiau žinomas bibliotekas, kurioms JS pasaulyje pradeda sektis, kurios populiarėja, o jų naudojimo laimės rodiklis yra aukštas. Nuoširdžiai raginu peržiūrėti šios svetainės turinį.
Apibendrinkime šį skyrių statistiniais duomenimis. Įvairių tipų grafikų analizė dažnai gali būti labai gera galimybė palyginti įvairius tam tikrų temų aspektus. Tačiau svarbu atsižvelgti į tai, kad sekti minios balsu nebūtinai bus protingiausia. Vietoj to galite priimti pagrįstą sprendimą naudodamiesi kai kuriomis iš diagramų analizės išmoktomis pamokomis.
Anksčiau minėjau žemesnį įėjimo į Vue - iš tiesų, tai leidžia šiek tiek greičiau susitelkti į tikrąjį programos kūrimą, naudoti įrankį ir iki minimumo sutrumpinti laiką, reikalingą susipažinti su aplinka, mechanika ir įvairiais naudojimo atvejais.
Apskritai mano nuomonė yra tokia. Vue labiau tinka žmonėms, kurie dar nėra susidūrę su front-end bibliotekomis. Be abejo, ji leis jums labiau skatinančiu būdu per trumpą laiką pasiekti patenkinamų rezultatų.
Vis dėlto pasakykime garsiai - kalbos, kuria naudojame konkrečius įrankius, žinių trūkumas anksčiau ar vėliau mums pakenks. Tai nereikšmingas elementas sprendžiant paprastus uždavinius, tačiau didėjant kuriamų programų sudėtingumui bus vis sunkiau ir sunkiau tinkamai kurti programas gerai neišmanant JavaScript.
Tikrai nekalbu apie gebėjimą rašyti sudėtingas funkcijas, nes šią dalį iš esmės gali pakeisti, pvz., pardavėjai. Turiu omenyje kai kurias dažniausiai pasitaikančias klaidas, kurias galima padaryti kalboje, ir nežinojimą, kad neteisingai elgiamasi ne dėl bibliotekos, o dėl kalbos naudojimo. Dažniausiai pasitaikanti klaida, kuri čia pasireiškia, yra vadinamasis nepakeičiamumas, t. y. žinios apie JavaScript atskaitos mechanizmą.
Negaliu pasiūlyti, kuri biblioteka yra geresnė kūrėjams, daugiau ar mažiau susipažinusiems su JavaScript. Tačiau žinau vieną dalyką - jei norite realiai įsivaizduoti, kaip atrodo kūrimas su abiem įrankiais “iš vidaus”, pabandykite parašyti programas kiekvienu iš jų. Tai suteiks jums idėją, leis pamatyti, kurie mechanizmai jums labiau patinka ir kas jums yra geresnis pasirinkimas.
Kaip jau minėjau anksčiau, abi bibliotekos veikia panašiose ekosistemose ir turi panašų požiūrį į programų kūrimą naudojant mažus komponentus. Abiem bibliotekoms sekasi gerai - nėra jokių požymių, kad artimiausiu metu kuri nors iš jų išnyks. Todėl darbo pasiūlymai abiejose išliks panašaus lygio.
Išvados paprastos - naudokite tai, kas jums tinka, kaupkite patirtį ir vertinkite. Tai padės jums susidaryti racionalų požiūrį į tai, ar konkrečiam projektui geriau naudoti vieną ar kitą biblioteką; taip pat stenkitės eksperimentuoti - niekas taip neišmoko, kaip praeityje padarytos klaidos.
Ne paslaptis, kad nėra aukso vidurio, kuris būtų geriausias sprendimas konkrečiam projektui. Ypač priekinėje dalyje taikomosioms programoms kurti naudojami įrankiai greitai sensta ir dažnai sunku susigaudyti naujausiose tendencijose.
Tačiau technologijos pasirinkimas nėra, arba bent jau neturėtų būti, priklausomai nuo to, kas atitinka dabartines tendencijas. Vietoj to, turėtume jį nukreipti į konkrečius lūkesčius ir prielaidas, susijusias su programa, kurią ketiname kurti. Kiekviena iš lyginamų bibliotekų turi savo stipriųjų ir silpnųjų pusių, kurios, suderintos su naudojimo atveju, leis mums pasirinkti tinkamiausią variantą.
Įdomus variantas gali būti didelių korporacijų technologijų santraukos, kuriose dažnai aprašomi jų naudojimo atvejai, kaip vyko ar vyksta didžiulių programų kūrimas ir kokias klaidas jos padarė praeityje. Galbūt tarp jų rasime atvejų, kurie bus ypač įdomūs renkantis biblioteką konkrečiam projektui.
Savybės, į kurias turėtume atsižvelgti, norėdami pasirinkti tinkamus įrankius kuriamai programai, yra šios: programos kūrimo laikas, paprastumas programų priežiūra, taikomosios programos sudėtingumą ir kūrėjų patirtį naudojant konkrečias bibliotekas.
Programuotojai yra žmonės, kurie praleidžia daugiausiai laiko prie mano lyginamų įrankių, todėl jie gali suteikti geriausią patarimą ir padėti jums pasirinkti geriausią variantą didžiuliame bibliotekų susidūrime. Būtent kurdami taikomąsias programas matote įvairias problemas, tiesiogiai kylančias dėl technologijos pasirinkimo, ir geriausiai matote, kokie dalykai trukdo naudoti konkrečią priemonę konkrečioms funkcijoms.
Kaip jau minėjau anksčiau - abi bibliotekos, atrodo, neišnyksta iš rinka, bent jau ne per artimiausius kelerius metus. Užuot priėmę sprendimus remdamiesi statistika ir nuomonėmis
įvairių žmonių iš interneto - gal geriau tiesiog pasikalbėti su kūrėjais.
Pristatykite jiems, ko tikimasi iš paraiškos, kiek laiko turime jai pateikti, ir leiskite laisvai pasikeisti nuomonėmis apie tai, ką jie mano apie abu sprendimus, prieš priimdami galutinį sprendimą.
Interneto karai paprastai, o gal ir visais atvejais, yra beprasmiški. Visada atsiras žmonių, kurie užsispyrusiai tvirtins, kad jų pasirinkimas yra geresnis, nepateikdami jokių racionalių argumentų, patvirtinančių jų sprendimą.
Užuot užsimerkę prieš konkrečius sprendimus, sutelkime dėmesį į analizę, pabandykime padaryti tinkamas išvadas ir jomis remdamiesi pakoreguokime arba atmeskime konkretų sprendimą.
Kaip rodo pavadinimas - neketinu karūnuoti kurios nors konkrečios bibliotekos kaip vaisto nuo kiekvieno skausmo. Vietoj to pateikiamos kelios hipotezės ir atskleidžiamos stipriosios bei silpnosios abiejų bibliotekų pusės. Pateikiau keletą patarimų, į ką atkreipti dėmesį renkantis tarp jų, kad priimtumėte išmintingą sprendimą, o ne vadovautumėtės tendencijomis ar atsitiktiniais žmonėmis iš interneto.
Kiekvienas įrankis gali pakankamai gerai atitikti projekto poreikius. Nė vienas iš jų artimiausiais metais greitai neišnyks iš rinkos. Abi turi galingas bendruomenes ir yra gana brandžios, o tai rodo, kad šioms dviem priemonėms sekasi gana gerai.
Galutinis pasirinkimas priklauso nuo jūsų. Tačiau, jei turite abejonių arba tiesiog norite aptarti savo atvejį su The Codest - nedvejodami susisiekite su mumis!
Skaityti daugiau:
Kodėl turėtumėte (tikriausiai) naudoti Typescript
Lithuanian 
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
French 
Polish 
Arabic 
Italian 
Spanish 
Dutch 
Estonian 
Greek 
Portuguese 
Czech 
Latvian 
Icelandic