PALAA TAAKSE
Verkon räjähdysmäinen kasvu, joka alkoi noin 10 vuotta sitten, on aiheuttanut suurta hämmennystä internetin maailmassa. Sen ansiosta selaimessa voi tehdä yhä enemmän asioita, mutta se myös muutti yleistä näkemystä sovelluskehityksestä. Tämä lähestymistapa vaati kuitenkin joitakin parannuksia selainpohjaisten sovellusten koodin ylläpitoon. Tämä oli ensimmäisten front-end-kehysten kehittämisen aikaa. Analysoin tänään mikroskoopin alla kahta niistä.
Pysähtykäämme hetkeksi ja miettikäämme, missä olemme. Totaalisena boomerina epäilen vilpittömästi, että noin 10 vuotta sitten kukaan olisi voinut ennustaa, että web-kehitys menisi näin pitkälle.
Työpöytäsovellukset ovat mennyttä aikaa, koska kaikki voidaan tehdä selaimessa. Itse asiassa myös sovellukset, joiden on käytettävä alemman tason sovellusrajapintoja, joita ei ole saatavilla selaimessa, kirjoitetaan selainmoottoreita ja -kieliä käyttäen, koska niiden ylläpito on helpompaa.
Mobiilisovellukset voidaan helposti korvata web-kehitykseen käytettävillä työkaluilla - ks. React Kotimainen, NativeScript. Lisäksi meillä on PWA, joka helposti "jäljittelee" mobiilisovellusten toimintaa. Lisäksi komponentit, jotka toimivat sovelluksessa, joka on kirjoitettu Vue tai React voi helposti jakaa erilaisia koodi elementtejä alustojen välillä.
Meidän on myönnettävä yksi asia - verkkosovellukset ovat tällä hetkellä voimanpesä, jota on vaikea laskea alakertaan. Käyttäjänä näen käyttäväni niitä käytännössä kaikkialla: kommunikoidessani Slackin kautta, käyttäessäni koodieditoria, tehdessäni esityksiä tai jopa kirjoittaessani blogiartikkelia.
On vaikea ennustaa, mitä muutaman vuoden kuluttua tapahtuu. WebAssembly on tulossa käyttöön, ja sen avulla voimme siirtää monimutkaisempia laskutoimituksia vaativat sovellukset selainmaailmaan. Yksi tosiasia pysyy kuitenkin muuttumattomana - on todella vaikea löytää estettä rakentaa web-tekniikoiden avulla sellainen sovellus, josta voimme vain unelmoida.
Palataanpa hetkeksi menneisyyteen, ennen kuin ensimmäiset merkittävämmät web-kehykset ilmestyivät ja sovelluksia kehitettiin imperatiivisella tavalla. Jokaista sivulla olevaa interaktiivista mekanismia käsiteltiin manuaalisesti, ja se oli vastuussa tietystä toiminnosta.
Paras esimerkki on jQuery-kirjasto, joka oli aikanaan yksi suosituimmista ratkaisuista yksinkertaisten tapahtumien käsittelyyn. Sen avulla toteutettiin erilaisia pudotusvalikoita, siirtymiä, animaatioita, laskureita ja vastaavia mekaniikkoja.
On syytä mainita, että monimutkaisemmissa sovelluksissa ongelmia havaittiin jo silloin - paikoissa, joissa eri, toisistaan riippumattomien osien piti esimerkiksi reagoida oikeaan napsautukseen tai jonkin asian kirjoittamiseen. Useimmissa sovelluksissa ei ollut eksplisiittistä tilaa, vaan ne pelastettiin esimerkiksi elementtien attribuuttien tai niiden luokkien avulla.
Tuolloin oli selvää, että nykyisestä lähestymistavasta puuttui reaktiivisuus - komponenttien jäsennelty tapa kommunikoida keskenään ja jakaa esimerkiksi tilansa tai erilaisia tapahtumia, mikä helpotti sovellusten ylläpitoa ja mahdollisti hyvän käyttökokemuksen tarjoamisen alhaisin kustannuksin.
Ajan myötä ensimmäiset front-end-kehykset alkoivat ilmestyä horisonttiin, ja niiden tarkoituksena oli jäsentää monimutkaisempien sovellusten arkkitehtuuria.
Nämä kehykset perustuivat pääosin MVC-malliin - jotkut, kuten Backbone.js, ehdottivat manuaalisempaa lähestymistapaa, kun taas toiset, kuten Knockout.js, käyttivät kaksisuuntaista datan sitomista.
Silti saattoi tuntua siltä, että sovelluksen kirjoittaminen oli vaikeampaa, vaati paljon enemmän koodausta eikä välttämättä tuottanut toivottuja tuloksia tai korvannut sovelluksen kehittämiseen menetettyä aikaa.
Tärkein syy siihen, miksi kultaisen keskitien löytäminen JS-ekosysteemistä oli vaikeaa, oli se, että se oli hieman outo tunnettujen ohjelmointikielet jotka ovat jo kauan olleet tiensä tasoittaneet.
Enkä halua tässä yhteydessä käsitellä tarkkaan sitä, millaisia polkuja eri kehysten kehittyminen on kulkenut historian aikana. On kuitenkin tärkeää huomata yksi asia - JS-ekosysteemin kypsymisaika selaimissa ei ollut helppo ja kohtasi monia koettelemuksia.
Tämä on ainoa syy siihen, miksi nykyään voimme rakentaa verkkosovelluksia ja kehittää niitä erittäin helposti ja vaivattomasti.
Sen sijaan, että heitellään lihaa, kuten internetissä on tapana, tutustutaan molempiin kirjastoihin, kerätään niistä tietoa ja vertaillaan niitä - sekä teoriassa että käytännössä.
HUOMAUTUS: Kuvaus mekanismeista, jotka toimivat Vue viittaa erityisesti versioon 2. Versiossa 3 on paljon merkittäviä muutoksia, mutta se ei ole todellinen kilpailija seuraaville tuotteille React tällä hetkellä, jos vain sen kypsyyden vuoksi - Vue 3 julkaisupäivä: 18. syyskuuta 2020.
Selvitetään yksi asia - kun tutustut syvällisemmin molempiin kirjastoihin, huomaat, että niissä on enemmän yhtäläisyyksiä kuin eroja. Jos jätetään sivuun kirjastojen käyttötapa sinänsä - molemmilla on hyvin samankaltaiset käsitteet siitä, miten ne toimivat. Molemmat perustuvat samanlaiseen ekosysteemiin, eikä niiden käyttö ole täysin erilaista.
● Paholainen piilee yksityiskohdissa - mitä useammin käytämme työkalua, sitä enemmän huomaamme sen eri ratkaisujen haittoja. Hyvä esimerkki tästä voi olla kaksisuuntainen datan sitominen, jota käytetään useimmiten kohteissa Vue v-mallin ominaisuutena: se helpottaa usein asioita, hoitaa monia asioita automaattisesti eikä vaadi lisätuen koodaamista arvojen muuttamista varten.
On kuitenkin tapauksia, joissa meidän on nimenomaan seurattava muutosyritystä ja reagoitava siihen, jolloin v-malliin perustuvien komponenttien käyttö pakottaa meidät usein pelleilemään muiden komponenttien kanssa. Vue mekaniikka, kuten laskennallinen ominaisuus, jolloin saavutettu vaikutus näyttää usein paljon huonommalta kuin manuaalisella lähestymistavalla;
● Toinen mielenkiintoinen näkökohta on JSX, joka on tällainen "vagrant" tapa mallintaa renderöityä sisältöä käyttämällä React. Kehittäjäyhteisö on eri mieltä siitä.
Havaintojeni perusteella näyttää siltä, että kehittäjät, jotka käyttävät muuta ympäristöä kuin JS:ää, esim. PHP tai C#, ovat taipuvaisempia mallintamaan näkymiä tavalla, joka on Vue tekee.
Yhteenvetona - mallit tunnetaan Vue mahdollistavat näkymien määrittelyn hyvin selkeällä ja tyylikkäällä tavalla, kun taas React:n JSX mahdollistaa niiden rakentamisen monissa tapauksissa nopeammin, räätälöitynä erityistarpeisiin ja usein vähemmän koodia erilaisten rakenteiden rakentamiseen;
● Tarkastellaan myös näiden kahden työkalun ekosysteemejä. Periaatteessa voimme sanoa, että ne eivät eroa toisistaan missään. Molempia kutsutaan kirjastoiksi syystä - ne tarjoavat pelkän vähimmäistason reaktiivisten verkkosovellusten tueksi.
Kun taas loput, jotka liittyvät API:n kanssa kommunikointiin, tiedonkulkuun, eri alasivujen ympärillä käytettäviin käyttöliittymäkomponentteihin, ovat niin sanottuja myyjiä - ulkopuolelta otettuja kirjastoja, jotka on liitettävä kunnolla osaksi projekti. Se on vähän kuin Lego-maailma: jos haluaa rakentaa yhtenäisen kokonaisuuden, se on koottava yksittäisistä pienistä palikoista.
Tämä allegoria viittaa juuri liitettyihin komponentteihin, jotka ovat sovellusten teho, jotka on luotu käyttämällä React tai Vue;
● Tärkeä asia, erityisesti ihmisille, joilla ei ole kovin paljon kokemusta JS-ympäristöstä, on tietyn kirjaston sisäänpääsyn taso. Toisin sanoen - työkalun monimutkaisuus, joka koostuu suorasta ajasta, joka sinun on käytettävä sen mekaniikan ymmärtämiseen.
Mielestäni yksi asia on todettava tässä yhteydessä yksiselitteisesti - kun kyseessä on Vue, se on paljon yksinkertaisempaa. Meillä on kaksisuuntainen datan sitominen, meillä on tyylikkäästi määritelty malli, joka on petollisen samanlainen kuin muiden kielten, esimerkiksi twigin, ratkaisut, ja lopuksi - meillä ei ole päänvaivaa, joka aiheutuu yksittäisten koukkujen toimintaa koskevien teorioiden oppimisesta ja tapauksista, joissa tiettyjä mekaniikkoja on käytettävä.
Suoraan massan äänen mukaan meneminen ei ole aivan hyvä valinta. Hyvä askel kohti hyvän päätöksen tekemistä on kuitenkin analysoida, mitä kirjastojen kanssa vuorovaikutuksessa olleet ihmiset sanovat.
Ja kyllä - tähdet githubissa voi olla indikaattori siitä, kuinka paljon tietyn kirjaston yhteisö osallistuu sen kehittämiseen, miten kehittäjät suhtautuvat siihen ja ovatko he kiinnostuneita siitä, mihin kirjasto on menossa. Insinöörit, jotka tähdittävät tiettyä arkistoa, saavat usein ilmoituksia uusista julkaisuista tai koodimuutoksista, mikä tarkoittaa heidän suoraa tietämystään kirjastosta.
Tähtien määrää githubissa ei kuitenkaan pitäisi pitää oraakkeleina - jokainen työkalusta pitävä kehittäjä ei jätä merkkiä - vaan pitäisin sitä merkkinä puhtaasta intohimosta, jolla kehittäjät suhtautuvat tiettyyn avoimen lähdekoodin projektiin.
Google Trends on tunnettu palvelu, jonka avulla voidaan tutkia kiinnostusta tiettyihin aiheisiin ajan mittaan. Vaikka se ei olekaan järkevä laadun tai käytön indikaattori, se voi tarjota kaikenlaisia analyysejä.
On helppo huomata, että viimeisen viiden vuoden aikana on kulkenut melko samankaltaisesti, kun verrataan tämänpäiväisen artikkelin kahta päähenkilöä. Kaavion perusteella voidaan tehdä seuraava perusjohtopäätös. React on korkeampi hakusanojen suosiossa suhteessa sen vastustajaan.
Selvyyden vuoksi todettakoon, että Google Trendsin kärjessä oleminen ei tarkoita, että kirjasto on parempi. Kyse on yleisön suosiosta, kuten aiemmin mainitsin - luultavasti useammat ihmiset ovat kuulleet tästä työkalusta, se on saattanut herättää enemmän kiinnostusta joukossa CTO:t, ohjelmistokehittäjät tai ihmiset, jotka haluavat vain oppia tietyn työkalun.
Vastaako tämä kuvaaja todellisuutta? Jonkin verran, kyllä. Yleisesti ottaen - tutkimukseen osallistuneista ihmisistä useammat osoittavat monipuolisesti kehittynyttä tietämystä seuraavista asioista React kuin Vue. Mitä mielipiteitä saatte puhumalla näiden ihmisten kanssa? Yritän hahmotella tätä seuraavassa kappaleessa.
JS:n tila on sivusto, joka tutkii vuosittain JavaScript:hen liittyvien teknologioiden parissa työskenteleviä henkilöitä. Sen tavoitteena on kerätä tietoa kehittäjiltä siitä, miten he suhtautuvat työkaluihin, joiden kanssa he työskentelevät päivittäin.
Kysymykset kattavat eri tarkoituksiin käytettävät yksittäiset työkalut - esimerkiksi front-endissä ja back-endissä käytettävät työkalut, mutta myös testaukseen, sovelluksen tilanhallintaan jne. käytettävät työkalut. Jokaiseen näistä kysymyksistä ei ole yksinkertainen kyllä/ei-vastaus, vaan sivustolla kysytään useita kysymyksiä itse työkalusta, kiinnostuksen kohteista, kokemuksista ja kokonaisarvioinnista, joka tiivistyy lauseeseen "Käyttäisitkö tätä työkalua tulevissa projekteissa?".
Sivuston avulla voit tehdä paljon analyysejä, vertailla asiaankuuluvia työkaluja ja joskus löytää vähemmän tunnettuja kirjastoja, jotka alkavat pärjätä hyvin JS-maailmassa, keräävät suosiota ja nauttivat samalla korkeasta "käytön ilo"-asteesta. Kannustan sinua vilpittömästi selaamaan tämän sivuston sisältöä.
Tiivistetään jakso tilastojen avulla. Erityyppisten kuvaajien analysointi voi usein olla erittäin hyvä vaihtoehto tiettyjen aiheiden eri näkökohtien vertailuun. On kuitenkin tärkeää ottaa huomioon, että joukon äänen seuraaminen ei välttämättä ole kaikkein fiksuinta. Sen sijaan voit tehdä tietoon perustuvan päätöksen käyttämällä joitakin kaavioanalyyseistä saatuja kokemuksia.
Aiemmin mainitsin, että kynnys päästä sisään on matalampi. Vue - Sen ansiosta voit todellakin keskittyä hieman nopeammin sovelluksen varsinaiseen kehittämiseen, käyttää työkalua ja vähentää minimiin aikaa, joka kuluu ympäristöön, mekaniikkaan ja erilaisiin käyttötapauksiin perehtymiseen.
Yleisesti ottaen olen sitä mieltä, että Vue sopii paremmin ihmisille, jotka eivät ole vielä käsitelleet front-end-kirjastoja. Sen avulla saat varmasti rohkaisevammalla tavalla tyydyttäviä tuloksia lyhyessä ajassa.
Sanotaan se kuitenkin ääneen - tietämättömyys kielestä, jolla käytämme tiettyjä työkaluja, vahingoittaa meitä ennemmin tai myöhemmin. Yksinkertaisissa asioissa se on merkityksetön tekijä, mutta kun luotujen sovellusten monimutkaisuus kasvaa, on yhä vaikeampaa rakentaa sovelluksia kunnollisella tavalla ilman hyvää tietämystä seuraavista kielistä JavaScript.
En oikeastaan tarkoita sitä, että pitäisi pystyä kirjoittamaan hienostuneita funktioita, koska tämä osa voidaan suurelta osin korvata esimerkiksi myyjillä. Viittaan joihinkin yleisiin virheisiin, joita kielellä voi tehdä, ja siihen, ettei ole tietoinen siitä, että virheellinen käyttäytyminen ei johdu kirjaston käytöstä, vaan kielen käytöstä. Yleisin virhe, joka ilmenee tässä, on niin sanottu muuttumattomuus - eli JavaScript:n viitemekanismin tunteminen.
En pysty ehdottamaan, kumpi kirjasto on parempi JavaScript:hen enemmän tai vähemmän perehtyneille kehittäjille. Mutta tiedän yhden asian - jos haluat saada todellisen käsityksen siitä, miltä kehitys molemmilla työkaluilla näyttää "sisältä päin" - yritä kirjoittaa sovelluksia kummallakin niistä. Näin saat käsityksen ja voit nähdä, mitkä mekanismit vetoavat sinuun enemmän ja mikä on sinulle parempi valinta.
Kuten aiemmin mainitsin - molemmat kirjastot perustuvat samanlaisiin ekosysteemeihin, ja niillä on samanlaiset näkemykset sovellusten rakentamisesta pienillä komponenteilla. Molemmat kirjastot menestyvät hyvin - mikään ei viittaa siihen, että kumpikaan niistä katoaisi lähitulevaisuudessa. Näin ollen työtarjoukset molemmissa pysyvät samalla tasolla.
Johtopäätökset ovat yksinkertaisia - käytä sitä, mikä sopii sinulle, kerää kokemuksia ja arvioi. Tämä auttaa sinua kehittämään rationaalisen lähestymistavan siihen, onko parempi käyttää yhtä tai toista kirjastoa tietyssä projektissa; yritä myös kokeilla - mikään ei opeta niin syvällisesti kuin menneisyydessä tehdyt virheet.
Ei ole mikään salaisuus, että ei ole olemassa mitään kultaista keskitietä, joka olisi paras ratkaisu tiettyyn hankkeeseen. Etenkin front-endissä sovellusten rakentamiseen käytettävät työkalut vanhenevat nopeasti, ja usein on vaikea löytää jalansijaa uusimmista trendeistä.
Teknologian valinta ei kuitenkaan ole, tai ainakaan sen ei pitäisi olla, sen mukaan, mikä sopii nykyisiin trendeihin. Sen sijaan meidän olisi suunnattava se kohti tiettyjä odotuksia ja oletuksia sovelluksesta, jonka aiomme rakentaa. Kullakin vertailtavista kirjastoista on omat vahvuutensa ja heikkoutensa, jotka sovitettuna käyttötapaukseen antavat meille mahdollisuuden tehdä järkevimmän valinnan.
Mielenkiintoiseksi vaihtoehdoksi voivat osoittautua suuryritysten teknologiayhteenvedot, joissa kuvataan usein niiden käyttötapauksia, miten valtavien sovellusten kehittäminen on edennyt tai on edennyt ja mitä virheitä ne ovat tehneet aiemmin. Ehkä löydämme niiden joukosta tapauksia, jotka ovat erityisen kiinnostavia, kun valitsemme kirjastoa tiettyä projektia varten.
Ominaisuudet, jotka meidän tulisi ottaa huomioon valitaksemme oikeat työkalut rakennettavaan sovellukseen, ovat: sovelluksen kehittämiseen kuluva aika, helppous sovelluksen ylläpito, sovelluksen monimutkaisuus ja kehittäjien kokemus tiettyjen kirjastojen käytöstä.
Kehittäjät ovat ihmisiä, jotka viettävät eniten aikaa vertailemillani työkaluilla, ja he voivat antaa parhaita neuvoja ja auttaa sinua tekemään parhaan valinnan kirjastojen suuressa yhteentörmäyksessä. Sovelluskehityksen aikana näkee erilaiset ongelmat, jotka johtuvat suoraan teknologian valinnasta, ja saa parhaan näkemyksen siitä, mitkä asiat heikentävät tietyn työkalun käyttöä tiettyihin ominaisuuksiin.
Kuten aiemmin mainitsin - molemmat kirjastot eivät näytä katoavan kirjastosta markkinatainakaan lähivuosina. Tilastoihin ja mielipiteisiin perustuvien päätösten sijaan
eri ihmisistä internetistä - ehkä parempi vaihtoehto on yksinkertaisesti puhua kehittäjien kanssa.
Esittele heille, mitä sovellukselta odotetaan, mitä aikaa meillä on sen toimittamiseen, ja anna heille mahdollisuus vaihtaa vapaasti mielipiteitä siitä, mitä mieltä he ovat molemmista ratkaisuista, ennen kuin teemme lopullisen päätöksen.
Internet-sodat ovat yleensä - tai ehkä joka tapauksessa - turhia. Aina on ihmisiä, jotka itsepäisesti väittävät, että heidän valintansa on parempi, esittämättä mitään järkeviä perusteluja päätöksensä tueksi.
Sen sijaan, että sokeudumme tietyistä valinnoista, keskitymme analyysiin, yritämme tehdä asianmukaisia johtopäätöksiä ja käyttää niitä tietyn ratkaisun mukauttamiseen tai hylkäämiseen.
Aivan kuten otsikko antaa ymmärtää - en aio kruunata mitään tiettyä kirjastoa parannuskeinona kaikkiin kipuihin. Sen sijaan esitellään muutamia hypoteeseja ja paljastetaan molempien kirjastojen vahvat ja heikot puolet. Olen antanut joitakin neuvoja siitä, mitä kannattaa etsiä, kun valitsee niiden välillä, jotta voi tehdä viisaan päätöksen eikä ohjautua trendien tai satunnaisten internet-ihmisten mukaan.
Kukin työkalu voi sopia projektin tarpeisiin riittävän hyvin. Kumpikaan niistä ei katoa markkinoilta nopeasti lähivuosina. Molemmilla on vahvat yhteisöt ja melkoinen kypsyys, mikä osoittaa, että näillä kahdella menee varsin hyvin.
Lopullinen valinta on sinun käsissäsi. Jos sinulla on kuitenkin epäilyksiä tai haluat vain keskustella tapauksestasi The Codest:n kanssa - ota rohkeasti yhteyttä!
Lue lisää:
Miksi sinun pitäisi (luultavasti) käyttää Typescriptiä?
Miten projektia ei saa tappaa huonoilla koodauskäytännöillä?
Finnish 
English 
German 
Swedish 
Danish 
Norwegian 
French 
Arabic 
Italian 
Japanese 
Korean 
Polish